The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Программирование под UNIX (C/C++)
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Странная проблема с g++ в x86_64 Linux, homelan (ok), 23-Май-07, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


2. "Странная проблема с g++ в x86_64 Linux"  +/
Сообщение от homelan (ok), 23-Май-07, 17:30 
>>char buf[256];
>> r=some_func(f,buf);
>> if(r) break; /*Не выполняющееся условие*/
>Что делает some_func() ? возможно портит стек
Ну, строго говоря, она не совсем такая, но смысл кода не потерялся.
Она читает из файла блок, обрабатывает его, и возвращает 0 без ошибки, 2 при конце файла, -1 при ошибке. Сама ф-ция some_func() проста как дверь, ничего военного не делает.
Она собрана в статическую либу, этот код я уже юзаю лет 5 без изменений. В 32-битных системах работает как часы.
Ответить | Правка | Наверх | Cообщить модератору

3. "Странная проблема с g++ в x86_64 Linux"  +/
Сообщение от vic (??), 23-Май-07, 18:20 
Намекаю еще раз:
>char buf[256];

> r=some_func(f,buf);
при переходе на 64 бит то что работало на 32 битах перестает работать достаточно часто.
Это не зависит от ее простоты или времени ее юзания на 32 битах. Так что либо код в студию либо смотрите что там у вас в ней эдакого :)


Ответить | Правка | Наверх | Cообщить модератору

4. "Странная проблема с g++ в x86_64 Linux"  +/
Сообщение от homelanemail (??), 23-Май-07, 19:40 
>Это не зависит от ее простоты или времени ее юзания на 32
>битах. Так что либо код в студию либо смотрите что там
>у вас в ней эдакого :)

Вот кусок кода, в котором вылет

int load_record(int db)
{
int fd;
adb_descr* d;
int rd;
char __rhdr[2];
bool deleted=false;

memset(&__rhdr[0],0,2);
//Get DB descriptor struct
if(db<0) return ADBE_INVDESC;
d=(adb_descr*)__db_descr.get(db);
if(!d) return ADBE_INVDESC;
if(d->closed) return ADBE_INVDESC;
if(!d->count) return ADBE_EOF; //Empty database
d->deleted=false;
//Get file descriptor
fd=d->fd;
//Read record header
rd=read(fd,&__rhdr[0],2);
/*DEBUG*/
printf("rd=%d\n",rd);


/**** ЗДЕСЬ У НАС ГРАБЛИ ****/
if(rd!=2) return errno;


/** И ЧТО САМОЕ ИНТЕРЕСНОЕ, И ЭТО ПРОХОДИТ!!! ХОТЯ, ИЗ ФАЙЛА РЕАЛЬНО НИЧЕГО НЕ  ПРОЧИТАНО!!!**/

if(memcmp(&rhdr[0],&__rhdr[0],2))
{
  //Deleted record?
  if(!memcmp(&dhdr[0],&__rhdr[0],2)) { d->deleted=true; deleted=true; goto _rdr; }
  return ADBE_CORRUPTED;
}
_rdr:
rd=read(fd,d->rec.data,d->rec.len);
if(!rd) return ADBE_EOF; //End of file

/** И ЭТО ТОЖЕ ПРОХОДИТ, СОБАКА БЕШЕНАЯ!!! **/

if(rd!=d->rec.len) return errno;
//Done
if(deleted) return ADBE_DELETED;
return 0;
}

Мда. Только даже такой пример наврядли чего полнее скажет. Тогда придется приводить весь код, а там файлов штук 5 точно задействовано, хотя я не совсем уверен, может, и больше. Это либа статическая в итоге получается.

Блин, хоть в какую сторону копать, а то у меня мОзги уже плавятся...
Я вообще не пойму, КАК такое может быть?
Ну, если бы я стек попортил, так вылетело бы все, а оно РАБОТАЕТ!!! Я проверял, 3 часа цикл вертело, и ни одного сбоя сбоку или ошибки... Только вот, что делает, совсем непонятно...

Ответить | Правка | Наверх | Cообщить модератору

5. "Странная проблема с g++ в x86_64 Linux"  +/
Сообщение от DeadMustdieemail (??), 24-Май-07, 13:07 
Стоит попробовать натравить на этот код valgrind.
Ответить | Правка | Наверх | Cообщить модератору

8. "Странная проблема с g++ в x86_64 Linux"  +/
Сообщение от vic (??), 24-Май-07, 14:18 
> d=(adb_descr*)__db_descr.get(db);
так и не узнали что же тут происходит((. тем более преобразование подозрительное.

кстати, pragma pack используется?

> /** И ЧТО САМОЕ ИНТЕРЕСНОЕ, И ЭТО ПРОХОДИТ!!! ХОТЯ, ИЗ ФАЙЛА
>РЕАЛЬНО НИЧЕГО НЕ  ПРОЧИТАНО!!!**/
откуда известно?
что strace грит?

про valgrind уже сказали.

да, а если вместо:
rd=read(fd,&__rhdr[0],2);
printf("rd=%d\n",rd); /*DEBUG*/
if(rd!=2) return errno; /**** ЗДЕСЬ У НАС ГРАБЛИ ****/

писать так:
if (rd = read(fd, __rhdr, 2)) != 2)
{
    printf("debug --- fd %d rd = %d errno %d text error %s\n", fd, rd, errno, strerror(errno));
    return errno;
}
то понятнее..

и еще, подозрительные двойные подчеркивания в названиях переменных и функций, как бы с чем-нить не пересеклось (в коде или дебаггере :)

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

6. "Странная проблема с g++ в x86_64 Linux"  +/
Сообщение от NuINu (??), 24-Май-07, 14:00 
>Намекаю еще раз:
>>char buf[256];
>
>> r=some_func(f,buf);
>при переходе на 64 бит то что работало на 32 битах перестает
>работать достаточно часто.
>Это не зависит от ее простоты или времени ее юзания на 32
>битах. Так что либо код в студию либо смотрите что там
>у вас в ней эдакого :)

Да чего мучаться заменить ее временно на вызов заглушки и проверить.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

7. "Странная проблема с g++ в x86_64 Linux"  +/
Сообщение от NuINu (??), 24-Май-07, 14:02 
>>Намекаю еще раз:
>>>char buf[256];
>>
>>> r=some_func(f,buf);
>>при переходе на 64 бит то что работало на 32 битах перестает
>>работать достаточно часто.
>>Это не зависит от ее простоты или времени ее юзания на 32
>>битах. Так что либо код в студию либо смотрите что там
>>у вас в ней эдакого :)
>
>Да чего мучаться заменить ее временно на вызов заглушки и проверить.

В заглушку поставить счетчик статик переменную, и на каждом двадцатом шаге возвращать 2 ку.или единицу.

Ответить | Правка | Наверх | Cообщить модератору

9. "Странная проблема с g++ в x86_64 Linux"  +/
Сообщение от vic (??), 24-Май-07, 14:19 
>>>Намекаю еще раз:
>>>>char buf[256];
>>>
>>>> r=some_func(f,buf);
>>>при переходе на 64 бит то что работало на 32 битах перестает
>>>работать достаточно часто.
>>>Это не зависит от ее простоты или времени ее юзания на 32
>>>битах. Так что либо код в студию либо смотрите что там
>>>у вас в ней эдакого :)
>>
>>Да чего мучаться заменить ее временно на вызов заглушки и проверить.
>
>В заглушку поставить счетчик статик переменную, и на каждом двадцатом шаге возвращать
>2 ку.или единицу.

точна :)

Ответить | Правка | Наверх | Cообщить модератору

10. "Странная проблема с g++ в x86_64 Linux"  +/
Сообщение от homelanemail (ok), 24-Май-07, 16:00 
Спасибо всем! Разобрался.
Добавил в строку g++ к опции '-Wall' дополнительно '-Wextra -Werror'
Поправил код, пересобрал все, что было.
В итоге в выводе появились числа, размер которых не берусь сказать... Очень большие числа, в общем.
Начал копать с gdb и обнаружил-таки где на самом деле оказались грабли.
Есть у меня код, который писался еще в 1996г. Так там в описании одной структуры все целочисленные member-ы были либо long, либо unsigned long. А в функциях новых везде int-ами пользовался или unsigned int-ами. А в x86_64 оказывается, что размер long и long long 8 байт, а int - 4. А под x86 было наоборот, long и int 4 байта, а long long - 8. Я, честно говоря, только сегодня узнал, что так дела обстоят. Везде во всем ранее написанном коде позаменял нафиг все long на int и все сразу заработало как надо. Эх, как говорится, век живи, век учись... :)
Ответить | Правка | Наверх | Cообщить модератору

11. "Странная проблема с g++ в x86_64 Linux"  +/
Сообщение от vic (??), 24-Май-07, 17:22 
>Везде во всем
>ранее написанном коде позаменял нафиг все long на int и все
>сразу заработало как надо.

Молодца, продолжаем учится:
1) читаем МЕГА полезную ссылку про портирование на 64 бита:
http://www-128.ibm.com/developerworks/linux/library/l-port64...

2) есть полезный файл stdint.h
содержит определения типов гарантированно имеющих нужный размер:
int8_t, int16_t, int32_t, int64_t и т.п. и соответствующие unsigned.
везде где только можно используем именно их. Никаких int или long, т.к. завтра наткнетесь на платформу с sizeof(int) == 8 и снова пляски с бубном.

3) перечитываем С/С++ стандарты, отмечаем что типы int, long, char и т.п. определены не как равные столько то байт (char=1), а как больше(!!!) или равно (char >= 1). Чтоб знать какие еще сюрпризы нас ждут.

Удачи.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру