On Thu, Jun 01, 2006 at 01:42:37PM +0200, Pavel Troller wrote:
Pavel Troller patrol@sinus.cz writes:
But now I'm unsure, maybe we are on a false track. I just examined +relay output again and I've found that immediately after the No-exec message the program seems to continue normally. The problem (exception loop in msvcrt) occurs many thousands lines later. I'm attaching preceding cca 1500 lines of the log.
It sounds like the no-exec workaround worked fine, and that you have some other problem. What does a +seh trace look like?
Hi Alexandre! +seh shows the following:
trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4d08b0 trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4d08b0 trace:seh:raise_exception eax=00000001 ebx=7fe02cd8 ecx=7fe02cd8 edx=00000003 esi=7fe02cd8 edi=6d4e0e90 trace:seh:raise_exception ebp=7fb2fd70 esp=7fb2fd68 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010293 trace:seh:call_stack_handlers calling handler at 0x401f00 code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4d08b0 handler=0x401f00 0x7fb2fa44 0x7fb2f984 semi-stub trace:seh:_except_handler3 filter = 0x401e62 trace:seh:_XcptFilter (-1073741819,0x7fb2f8c0) trace:seh:_except_handler3 filter returned CONTINUE_SEARCH trace:seh:_except_handler3 reached TRYLEVEL_END, returning ExceptionContinueSearch trace:seh:call_stack_handlers handler at 0x401f00 returned 1 trace:seh:call_stack_handlers calling handler at 0x7b82be80 code=c0000005 flags=0 fixme:seh:check_no_exec No-exec fault triggered at 0x6d4d08b0, enabling work-around trace:seh:call_stack_handlers handler at 0x7b82be80 returned 0 trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4db3ef trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4db3ef trace:seh:raise_exception eax=7fb2fb28 ebx=797f2e80 ecx=7fb2fbec edx=7fb2fcb0 esi=7fe02cd8 edi=6d4db3ef trace:seh:raise_exception ebp=7fb2fb74 esp=7fb2faf8 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010246 trace:seh:call_stack_handlers calling handler at 0x6d4b4bba code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4db3ef handler=0x6d4b4bba 0x7fb2f7d4 0x7fb2f714 semi-stub trace:seh:_except_handler3 filter = 0x6d469332 trace:seh:_except_handler3 filter returned CONTINUE_EXECUTION trace:seh:call_stack_handlers handler at 0x6d4b4bba returned 0 trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4d5d7b trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4d5d7b trace:seh:raise_exception eax=7fb2fb28 ebx=797f2e80 ecx=7fb2fbec edx=7fb2fcb0 esi=7fe02cd8 edi=6d4db3ef trace:seh:raise_exception ebp=7fb2fb74 esp=7fb2faf8 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010246 trace:seh:call_stack_handlers calling handler at 0x6d4b4bba code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4d5d7b handler=0x6d4b4bba 0x7fb2f7d4 0x7fb2f714 semi-stub trace:seh:_except_handler3 filter = 0x6d469332 trace:seh:_except_handler3 filter returned CONTINUE_EXECUTION trace:seh:call_stack_handlers handler at 0x6d4b4bba returned 0
It looks that the first exception is the No-exec, then there is one more lonely one (at 0x6d4db3ef) and the third one (at 0x6d4d5d7b) is the first invocation of the looping one - this one repeats in the log at the same address forever.
Please check the audit log whether a SELINUX audit event happened. (/var/log/audit/audit.log I think.)
Ciao, Marcus