At 12:17 01/04/03 -0800, you wrote: >Adam Gundy <[EMAIL PROTECTED]> writes: > >> a new version of the valgrind patch has been uploaded to sourceforge - >> the only change is a small fix to the signal handling which should >> prevent "signal handler frame" uninitialized errors. >> >> >> http://sourceforge.net/tracker/index.php?func=detail&aid=710006&group_id=46268&atid=445588 >> >> comments? bug reports? success stories? > >I played a bit with it, it works pretty well, and I have already fixed >a few bugs found with it. Great work! > >I have also applied those of your fixes that seemed correct, the rest >will need a bit more work The signal stuff in particular is not going >to work properly with NPTL, it would be really better if we could >somehow make valgrind use real threads. I have no idea if this is >possible though.
which part of the signal stuff won't work? all that has happened is that the "kill( <pid>, SIGUSR1 )" has moved from the wineserver to the client (for 'local' threads). I thought that the NPTL stuff still wanted a PID-per-thread model just so it can do this? OTOH if you can *really* switch to a pure pthreads model, that should be no problem since valgrind comes with a pthread library... as to making valgrind use real threads, I think that is a BIG job, and unlikely to happen, since the only thing that wants 'real' threads is WINE - everything else is happy with pthreads. Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.
