захламление регистров - проблема

но вот один раз вывесилось на push dword [ebx+10], причём ebx имел значение указывающее куда то в жопу (0xFF**)

Эта жопа называется kernel space ;)

получается pthread_create или usleep изменили значение ebx - такое разве допускается?!

Нет. Версию компилятора, libc, ядра и кусок кода в студию.

>получается pthread_create или usleep изменили значение ebx - такое разве допускается?!

По идее это должно зависеть от соглашения о вызове. Почему и нет. Очень вероятно, что тебе надо самому беспокоится о сохранении регистра ebx.

я так пологаю с таким же успехом там могло что угодно быть, не только FF**. прога юзермоде, высоконагружаемое сокетное приложение дело вообще в том, что чудодейственным образом ebx был изменён в процессе вызова thread_create или usleep

кусок кода смотри в первом сообщении пишу на fasm, компилирую им же, собираю через gcc -s -pthread bs.o -o bs -lc

т.е. что пишу, то и вижу в отладчике лишних инструкций не добавляется

запускал на freebsd 7.3 stable версию libc хз как посмотреть. используется libc.so.7

в соглашениях как раз ebx esi edi ebp должны сохраняться

Баг. Или fbsd не следует

SYSTEM V
APPLICATION
BINARY INTERFACE
Intel386™ Architecture
Processor Supplement

может железка глючная? :)

>что чудодейственным образом ebx был изменён в процессе вызова thread_create или usleep

можно в дизасме посмотреть, что они делают с ebx... только придётся, наверное, вглубь вплоть до ядра вгрызаться)

отладчик показывает, что обе функции внутри libc сохраняют в стеке регистры и восстанавливают их при выходе

где нибудь описано нестандартное может поведение при обрывании выполнения функций?

Ну функция то может оборваться только по рет... Если в теле функции нет лишних рет и нет джампов через то метро, где регистры возвращаются из стэка, то это чудо.

Для начала попробуй стабильно воспроизвести, как уже сказали похоже на баг в libc/kernel, по текущим данным не починишь.