|
From: Marcus C. <cre...@in...> - 2006-03-21 16:58:35
|
Hi all, I am working on an incremental garbage collector[1] for XEmacs[2]. I'd like to execute XEmacs with the new GC under valgrind to catch all the little memory problems that are really hard to identify without valgrind. Unfortunatelly, I run in a problem here, since the incremental garbage collector's write barrier messes with memory protection and signal handling: The garbage collector uses a "Virtual Dirty Bit Write Barrier" that makes uses of the operating system's memory-protection mechanisms: The write barrier write-protects memory pages containing heap objects, typically with `mprotect'. If the mutator tries to modify these objects by writing into the write-protected page, the operating system generates a fault, typically SIGSEGV. The write barrier catches this fault by installing it's own signal handler, reads out the error-causing address and can thus identify the updated object and page. The write barrier's signal handler checks if the caught SIGSEGV is provoked on purpose or if it really is an invalid memory access. The provoked ones trigger actions to record the modified object, the invalid ones abort the running XEmacs via SIGABRT. Valgrind catches the first SIGSEGV and shows the backtrace. Then, it does not pass the signal back to the program or the program's signal handler, but kills the program. This is not the desired action for my special case. Is there a way to not have valgrind act upon a SIGSEGV or have valgrind pass it back to the program's signal handler? For example, I can still debug the incremental GC in gdb by masking off SIGSEGV: gdb> handle SIGSEGV nopass nostop noprint I took a look at valgrind's suppressions, but it seems to me that this is not the kind of scenario the suppressions are supposed to work. Any hints? Is it possible to use valgrind with such a write barrier? Thanks, Footnotes: [1] http://www.crestani.de/xemacs [2] http://www.xemacs.org -- Marcus |
|
From: Tom H. <to...@co...> - 2006-03-21 18:05:56
|
In message <vpd...@in...>
Marcus Crestani <cre...@in...> wrote:
> Valgrind catches the first SIGSEGV and shows the backtrace. Then, it
> does not pass the signal back to the program or the program's signal
> handler, but kills the program. This is not the desired action for my
> special case.
This is not true - if you have installed a SEGV handler then
valgrind will honour it. I think you need to provide more
information so we can diagnose the real problem.
I suggest you open a bug and provide the --trace-signals=yes
output from valgrind.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-03-21 19:09:19
|
On Tuesday 21 March 2006 18:04, Tom Hughes wrote: > In message <vpd...@in...> > > Marcus Crestani <cre...@in...> wrote: > > Valgrind catches the first SIGSEGV and shows the backtrace. Then, it > > does not pass the signal back to the program or the program's signal > > handler, but kills the program. This might mean it doesn't think you registered a handler for SIGSEGV, since as Tom says if you had, V would have honoured it. > I suggest you open a bug and provide the --trace-signals=yes > output from valgrind. Or better still - construct a small test program which shows the problem. That would make it relatively easy for us to figure out what is going on. J |
|
From: Julian S. <js...@ac...> - 2006-03-21 23:06:05
|
Thanks for filing #124035. I can reproduce the problem using your valgrind-test.c. I can also get rid of the problem by giving the flag --vex-iropt-precise-memory-exns=yes to Valgrind. The problem is your segfault handler returns and so restarts the faulting instruction, having screwed around with the page permissions. By default Valgrind optimises the code it generates in such a way that the simulated registers are not always up to date, so when the exception happens, in effect some of the most recent changes to the simulated registers are lost. --vex-iropt-precise-memory-exns=yes disables this optimisation at the cost of some performance overhead. I have to ask, is it really a good idea to add this to XEmacs? Doing so violates POSIX compliance (POSIX does not allow segfault handlers to return, IIRC, or says that your process state is undefined after such an event, or something bad like that.) J On Tuesday 21 March 2006 19:09, Julian Seward wrote: > On Tuesday 21 March 2006 18:04, Tom Hughes wrote: > > In message <vpd...@in...> > > > > Marcus Crestani <cre...@in...> wrote: > > > Valgrind catches the first SIGSEGV and shows the backtrace. Then, it > > > does not pass the signal back to the program or the program's signal > > > handler, but kills the program. > > This might mean it doesn't think you registered a handler for > SIGSEGV, since as Tom says if you had, V would have honoured it. > > > I suggest you open a bug and provide the --trace-signals=yes > > output from valgrind. > > Or better still - construct a small test program which shows the > problem. That would make it relatively easy for us to figure out > what is going on. > > J > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Dennis L. <pla...@in...> - 2006-03-22 00:31:30
|
Am Dienstag, den 21.03.2006, 23:05 +0000 schrieb Julian Seward: > I have to ask, is it really a good idea to add this to XEmacs? > Doing so violates POSIX compliance (POSIX does not allow segfault > handlers to return, IIRC, or says that your process state > is undefined after such an event, or something bad like that.) POSIX (IEEE Std 1003.1, 2004 Edition) says, about the signal handler function: If and when the function returns, if the value of sig was SIGFPE, SIGILL, or SIGSEGV or any other implementation-defined value corresponding to a computational exception, the behavior is undefined. This is an exact copy of the text of ISO9899:1999 7.14.1.1-3 greets Dennis |
|
From: Marcus C. <cre...@in...> - 2006-03-22 12:36:11
|
>>>>>"JS" == Julian Seward <js...@ac...> writes: JS> Thanks for filing #124035. I can reproduce the problem using JS> your valgrind-test.c. I can also get rid of the problem by JS> giving the flag --vex-iropt-precise-memory-exns=yes to Valgrind. Works for me, too. JS> The problem is your segfault handler returns and so restarts the JS> faulting instruction, having screwed around with the page permissions. JS> By default Valgrind optimises the code it generates in such a way JS> that the simulated registers are not always up to date, so when JS> the exception happens, in effect some of the most recent changes JS> to the simulated registers are lost. JS> --vex-iropt-precise-memory-exns=yes disables this optimisation JS> at the cost of some performance overhead. Thanks for clearing this up so quickly! JS> I have to ask, is it really a good idea to add this to XEmacs? JS> Doing so violates POSIX compliance (POSIX does not allow segfault JS> handlers to return, IIRC, or says that your process state JS> is undefined after such an event, or something bad like that.) Yes, I am aware of that. But currently, it is the only way to advance the development of the garbage collector. We are not yet able to annotate each pointer update in the sources, which would be the only alternative to the virtual dirty bit write barrier. So the only way to get a working write barrier is with the assistance from the virtual memory system. Although not fully covered by POSIX, most operating systems support a generic virtual dirty bit write barrier. Actually, XEmacs with my incremental garbage collector runs on many kinds of Linux, FreeBSD, Solaris, Mac OS X, native Windows, and Cygwin. And now even under valgrind. There are some other systems around that use the same techniques. The new XEmacs collector for example uses a lot of the ideas of PLT's MzScheme[1] and the Boehm-Demers-Weiser conservative garbage collector[2]. All don't seem to have problems with it. Again, thanks very much for your help! Footnotes: [1] http://www.plt-scheme.org/software/mzscheme [2] http://www.hpl.hp.com/personal/Hans_Boehm/gc -- Marcus |
|
From: Marcus C. <ma...@cr...> - 2006-03-21 22:41:16
|
>>>>>"JS" == Julian Seward <js...@ac...> writes: JS> Or better still - construct a small test program which shows the JS> problem. That would make it relatively easy for us to figure out JS> what is going on. I just filed a bug report with a test program: http://bugs.kde.org/show_bug.cgi?id=124035 Please let me know if you need more info. Thanks, -- Marcus |