Re: Trap flag handling change in 2.6.10-bk5 broke Kylix debugger

[Paulo Marques <pmarques@grupopie.com>]

Linus Torvalds wrote:
> [...]
> Hmm. You could try variations on the appended patch. Try changing the 
> "#if 0" to "#if 1" in various combinations, to see which one Kylix seems 
> to care about.

Sorry about the delay, but being Valentine's day and all changes our 
priorities a bit ;)

Anyway, a friend of mine tested the patch and reported that the 
combinations 000 (all comented out), 001 (the first 2 commented out, but 
the last one not) and 110 (...) still hung the debugger. I suppose these 
were all the combinations he tested.

Tonight I'll have more time to test this again and we can probably have 
a more interactive debug session.

In the mean time, just a few more data points. The debugger seems to use 
LinuxThreads and only works with LD_ASSUME_KERNEL=2.4.1, even on a 
2.6.10 kernel.

If we don't set this, the debugger hangs in a different way. Apparently 
it is waiting on a signal, it has a signal pending that is one of the 
first real-time signals (the ones used by LinuxThreads), but its signal 
mask is blocking it.

Anyway, I thought of trying to attach a strace to the debugger tonight 
to try to see exactly what the debugger is doing. Is this supposed to 
work? Or trying to trace a process that is itself tracing another 
process a no-no and can give unreliable results?

-- 
Paulo Marques - www.grupopie.com

Pointy-Haired Boss: I don't see anything that could stand in our way.
            Dilbert: Sanity? Reality? The laws of physics?