|
From: Nick R. <ni...@sn...> - 2004-12-06 23:54:43
|
[Please cc to me as I'm not on the list] > 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. I'm not familiar with brk(), I'll read up about it. Are you saying that you shouldn't use brk() if you want to analyse your program with Valgrind? > xemacs doesn"t have any such stupidness. xemacs doesn't seem to work with Valgrind, either: /usr/local/bin/valgrind --tool=memcheck /usr/bin/xemacs **19358** Program aborting because of call to malloc_set_state ==19358== at 0x1B8F9AFA: VALGRIND_PRINTF_BACKTRACE (../include/valgrind.h:230) ==19358== by 0x1B900B99: malloc_set_state (vg_replace_malloc.c:294) ==19358== by 0x80ADCA6: main (in /usr/bin/xemacs-21.4.9) > "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. I think Emacs does use the standard malloc/free routines by default now (gmalloc.c is included but doesn't get used in my build): /* Define to 1 if you are using the GNU C Library. */ #define DOUG_LEA_MALLOC 1 > 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. I've tried it now with --with-x-toolkit=no, and even --without-x, but it still gives the same error message. Nick |