|
From: Nick R. <ni...@sn...> - 2004-12-04 21:39:47
|
Hi, In the documentation for Valgrind, it states: > Emacs is known not to work with Valgrind because Emacs has its own > memory-management scheme. Emacs works fine if you build it using the > standard malloc/free routines. Could someone please clarify, more explicitly, what "build it using the standard malloc/free routines" entails? Thanks, Nick |
|
From: Nicholas N. <nj...@ca...> - 2004-12-06 09:59:18
|
On Sun, 5 Dec 2004, Nick Roberts wrote: > In the documentation for Valgrind, it states: > >> Emacs is known not to work with Valgrind because Emacs has its own >> memory-management scheme. Emacs works fine if you build it using the >> standard malloc/free routines. > > Could someone please clarify, more explicitly, what "build it using the > standard malloc/free routines" entails? I'm not sure if that's still true -- I think there was a long-standing bug that caused Valgrind to fail to run Emacs. So it might work. However, the error messages may be better if you build it to use malloc/free, since then Valgrind can see more of what's happening. As for how to do that, I don't know -- I guess read the Emacs docs or Google for it. N |
|
From: Julian S. <js...@ac...> - 2004-12-06 10:16:22
|
On Monday 06 December 2004 09:59, Nicholas Nethercote wrote: > On Sun, 5 Dec 2004, Nick Roberts wrote: > > In the documentation for Valgrind, it states: > >> Emacs is known not to work with Valgrind because Emacs has its own > >> memory-management scheme. Emacs works fine if you build it using the > >> standard malloc/free routines. > > > > Could someone please clarify, more explicitly, what "build it using the > > standard malloc/free routines" entails? I've had varying success running GNU emacs on recent V's; one time it worked, but another time it didn't. I think it is to do with emacs doing something wildly non-portable with brk() and being confused by V's behaviour. xemacs doesn't have any such stupidness. "build it using the standard malloc/free routines" is just a ./configure option to emacs, IIRC. Something like --use-system-malloc -- you'll have to check, I don't really remember. Note I also have to use --with-x-toolkit=NONE in order to get a build of emacs which doesn't simply segfault at startup. J |
|
From: Nick R. <ni...@sn...> - 2004-12-06 19:53:15
|
> > In the documentation for Valgrind, it states: > > > >> Emacs is known not to work with Valgrind because Emacs has its own > >> memory-management scheme. Emacs works fine if you build it using the > >> standard malloc/free routines. > > > > Could someone please clarify, more explicitly, what "build it using the > > standard malloc/free routines" entails? > > > I'm not sure if that's still true -- I think there was a > long-standing bug that caused Valgrind to fail to run Emacs. > So it might work. However, the error messages may be better > if you build it to use malloc/free, since then Valgrind can > see more of what's happening. As for how to do that, I don't know > -- I guess read the Emacs docs or Google for it. I downloaded 2.2.0, and to some extent you're right. Valgrind (memcheck) now works with temacs (which dumps out the executable, emacs) where previously (2.0.0) it ended with a segmentation fault - thankyou. However, Valgrind still fails with Emacs: ==2325== Invalid free() / delete / delete[] ==2325== at 0x1B900335: free (vg_replace_malloc.c:153) ==2325== by 0x81467B6: (within /usr/bin/emacs-21.2) ==2325== by 0x8054A15: (within /usr/bin/emacs-21.2) ==2325== by 0x80F1A38: (within /usr/bin/emacs-21.2) ==2325== Address 0x82B92D0 is not stack'd, malloc'd or (recently) free'd emacs: Memory exhausted--use M-x save-some-buffers RET The documentation suggests that the author successfully built Emacs to work with Valgrind, although it could be a teaser like Fermat's last theorem! Nick |