валится процесс на фряхе на лине все в норме:
- 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() ?

• Непонятки...,NuINu, 21:03 , 11-Май-11
  • Непонятки...,nikto, 21:19 , 11-Май-11
  • Непонятки...,nikto, 21:21 , 11-Май-11
    • Непонятки...,NuINu, 18:27 , 12-Май-11
      • Непонятки...,nikto, 20:57 , 15-Май-11

>[оверквотинг удален]
> - 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() ?

хз

..
>>>  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)

..
>>>  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)

>[оверквотинг удален]
>> советую присмотреться к этой записи, и посмотреть насколько велик данный файл.
> упс, пожадничал на трафике - секвестировал пару строк(тяжелое наследие "модемного режима"),
> а файл нулевой:
>>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
может где нибудь идет переполнение в массивах(строках) и оно затирает значение локальных переменных.

> А кто вызывает 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)