The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Непонятки..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Программирование под UNIX (C/C++)
Изначальное сообщение [ Отслеживать ]

"Непонятки..."  +/
Сообщение от nikto on 11-Май-11, 18:54 
валится процесс на фряхе на лине все в норме:
- write(0x5152... - "псевдо отладка"
- выхлоп "ktrace -i -d -t+ -p 5672"

>  5672 proc CALL  write(0x5152c,0xbfbfeba0,0x8)
>  5672 proc RET   write -1 errno 9 Bad file descriptor
>  5672 proc CALL  lseek(0x6,0,<invalid=673239296>,0)
>  5672 proc RET   lseek 0
>  5672 proc CALL  write(0x51590,0xbfbfebb0,0x4)
>  5672 proc RET   write -1 errno 9 Bad file descriptor
>  5672 proc CALL  write(0x6,0x8062160,0xa)
>  5672 proc RET   write -1 errno 27 File too large

...
"5672 proc CALL  lseek(0x6,0,<invalid=673239296>,0)"

- какого -> <invalid=673239296> ?
  если все параметры передаюся явно - через константы в вызове,
  окромя фйлового дескрипторa ?
- почему 4 параметра в трасировке lseek() ?

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

Оглавление

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


1. "Непонятки..."  +/
Сообщение от NuINu (??) on 11-Май-11, 21:03 
>[оверквотинг удален]
> - write(0x5152... - "псевдо отладка"
> - выхлоп "ktrace -i -d -t+ -p 5672"
>>  5672 proc CALL  write(0x5152c,0xbfbfeba0,0x8)
>>  5672 proc RET   write -1 errno 9 Bad file descriptor
>>  5672 proc CALL  lseek(0x6,0,<invalid=673239296>,0)
>>  5672 proc RET   lseek 0
>>  5672 proc CALL  write(0x51590,0xbfbfebb0,0x4)
>>  5672 proc RET   write -1 errno 9 Bad file descriptor
>>  5672 proc CALL  write(0x6,0x8062160,0xa)
>>  5672 proc RET   write -1 errno 27 File too large

советую присмотреться к этой записи, и посмотреть насколько велик данный файл.


> ...
> "5672 proc CALL  lseek(0x6,0,<invalid=673239296>,0)"
> - какого -> <invalid=673239296> ?
>   если все параметры передаюся явно - через константы в вызове,

это то можно обьяснить, в стеке это лишь область памяти в которой передается желаемое смещение, возможно процедура lseek ее использует во время работы и меняет. те на входе 0, а после выхода уже некое значение.

это лишь догадка, надо код смотеть.

ну вообщем 27 ошибка. в линуксе тоже самое.


>   окромя фйлового дескрипторa ?
> - почему 4 параметра в трасировке lseek() ?

хз

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

2. "Непонятки..."  +/
Сообщение от nikto on 11-Май-11, 21:19 
..
>>>  5672 proc CALL  lseek(0x6,0,<invalid=673239296>,0)
>>>  5672 proc RET   lseek 0

...
>>>  5672 proc RET   write -1 errno 27 File too large
> советую присмотреться к этой записи, и посмотреть насколько велик данный файл.

упс, пожадничал на трафике - секвестировал пару строк(тяжелое наследие "модемного режима"), а файл нулевой:
>[оверквотинг удален]
>>   если все параметры передаюся явно - через константы в вызове,
> это то можно обьяснить, в стеке это лишь область памяти в которой
> передается желаемое смещение, возможно процедура lseek ее использует во время работы
> и меняет. те на входе 0, а после выхода уже некое
> значение.
> это лишь догадка, надо код смотеть.
> ну вообщем 27 ошибка. в линуксе тоже самое.
>>   окромя фйлового дескрипторa ?
>> - почему 4 параметра в трасировке lseek() ?
> хз

Есть подозрение - обертка внутрисистемная(бегло глянул на сорцы dd и в ман`ах lseek),
и похоже устанавливается указатель внутри файла, за пределами текущего размера, на 673239296 -> и на write() вылетает

"Будем копать" (c)

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

3. "Непонятки..."  +/
Сообщение от nikto on 11-Май-11, 21:21 
..
>>>  5672 proc CALL  lseek(0x6,0,<invalid=673239296>,0)
>>>  5672 proc RET   lseek 0

...
>>>  5672 proc RET   write -1 errno 27 File too large
> советую присмотреться к этой записи, и посмотреть насколько велик данный файл.

упс, пожадничал на трафике - секвестировал пару строк(тяжелое наследие "модемного режима"), а файл нулевой:

>5672 proc STRU  struct stat {dev=70, ino=56371, mode=-rw------- , nlink=1, uid=1001, gid=1110, rdev=0, atime=0, stime=1286974484, ctime=1305123352, birthtime=1286974484, size=0, blksize=16384, blocks=0, flags=0x0 }
>5672 proc RET   stat 0

...
> это то можно обьяснить, в стеке это лишь область памяти в которой
> передается желаемое смещение, возможно процедура lseek ее использует во время работы
> и меняет. те на входе 0, а после выхода уже некое
> значение.
> это лишь догадка, надо код смотеть.
> ну вообщем 27 ошибка. в линуксе тоже самое.
>>   окромя фйлового дескрипторa ?
>> - почему 4 параметра в трасировке lseek() ?
> хз

Есть подозрение - обертка внутрисистемная(бегло глянул на сорцы dd и в ман`ах lseek),
и похоже устанавливается указатель внутри файла, за пределами текущего размера, на 673239296 -> и на write() вылетает

"Будем копать" (c)

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

4. "Непонятки..."  +/
Сообщение от NuINu (??) on 12-Май-11, 18:27 
>[оверквотинг удален]
>> советую присмотреться к этой записи, и посмотреть насколько велик данный файл.
> упс, пожадничал на трафике - секвестировал пару строк(тяжелое наследие "модемного режима"),
> а файл нулевой:
>>5672 proc STRU  struct stat {dev=70, ino=56371, mode=-rw------- , nlink=1, uid=1001, gid=1110, rdev=0, atime=0, stime=1286974484, ctime=1305123352, birthtime=1286974484, size=0, blksize=16384, blocks=0, flags=0x0 }
>>5672 proc RET   stat 0
> Есть подозрение - обертка внутрисистемная(бегло глянул на сорцы dd и в ман`ах
> lseek),
> и похоже устанавливается указатель внутри файла, за пределами текущего размера, на 673239296
> -> и на write() вылетает
> "Будем копать" (c)

А кто вызывает lseek  с таким большим значением? может у вас там косяк где нибудь?
бросьте ktrace и запускайте в gdb. и смотрите значения сразу перед вызовом lseek
может где нибудь идет переполнение в массивах(строках) и оно затирает значение локальных переменных.

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

5. "Непонятки..."  +/
Сообщение от nikto on 15-Май-11, 20:57 
> А кто вызывает lseek  с таким большим значением? может у вас
> там косяк где нибудь?
> бросьте ktrace и запускайте в gdb. и смотрите значения сразу перед вызовом
> lseek
> может где нибудь идет переполнение в массивах(строках) и оно затирает значение локальных
> переменных.

С проблемой границ массивов знаком, все тип-топ по этому направлению.
В том то и анекдот, вызов был с нулевым параметром, т.е установить на начало файла.
Помогло явное приведение типов.
Суть, на фряхе:

bla_bla_fun(int fd, off_t off, char *buf, unsigned len)
{
...
lseek(...);
...
}

Было: bla_bla_fun(fd,0,buf,len)
Стало: bla_bla_fun(fd,(off_t)0,buf,len)


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

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

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




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

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