Summary: | emacs fails to compile with usersandox and USE=leim | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | TGL <tom.gl> |
Component: | Current packages | Assignee: | Emacs project <emacs> |
Status: | VERIFIED TEST-REQUEST | ||
Severity: | normal | ||
Priority: | Low | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
TGL
2005-05-06 12:29:39 UTC
Sorry but the bug is not reproduceable to me ;( Does anyone else confirm this bug? If it can be of any help, i've tried again (and got exactly the same behavior) and here is what gdb says of the dumped core file: (gdb) bt #0 0xb7bf6495 in free () from /lib/tls/libc.so.6 #1 0xffffffd8 in ?? () #2 0xffffffd8 in ?? () #3 0xbfffcd58 in ?? () #4 0xffffffd8 in ?? () #5 0xb7bf63b6 in free () from /lib/tls/libc.so.6 #6 0x00000001 in ?? () #7 0x0000002f in ?? () #8 0x0843d100 in ?? () #9 0x6b727574 in ?? () #10 0x00687369 in ?? () #11 0x20202020 in ?? () #12 0x08489748 in ?? () #13 0x00001000 in ?? () #14 0x53492e52 in ?? () #15 0xb7bf53bf in malloc_usable_size () from /lib/tls/libc.so.6 #16 0xb7cc2820 in __malloc_initialize_hook () from /lib/tls/libc.so.6 #17 0x00000038 in ?? () #18 0xb7cc2820 in __malloc_initialize_hook () from /lib/tls/libc.so.6 #19 0xbfffcdd0 in ?? () #20 0xb7bf53bf in malloc_usable_size () from /lib/tls/libc.so.6 #21 0xb7cb3b0f in in6addr_any () from /lib/tls/libc.so.6 #22 0xb7cb3b0f in in6addr_any () from /lib/tls/libc.so.6 #23 0xb7cc2858 in __malloc_initialize_hook () from /lib/tls/libc.so.6 #24 0x74207470 in ?? () #25 0x72000a6f in ?? () #26 0xb7cb3b0f in in6addr_any () from /lib/tls/libc.so.6 #27 0xb7cb3b0f in in6addr_any () from /lib/tls/libc.so.6 #28 0xb7bf59cb in malloc_trim () from /lib/tls/libc.so.6 #29 0xb7ffac6c in __libc_memalign () from /lib/ld-linux.so.2 #30 0xb7bf63b6 in free () from /lib/tls/libc.so.6 #31 0xb7cc2858 in __malloc_initialize_hook () from /lib/tls/libc.so.6 #32 0x00000008 in ?? () #33 0x00000040 in ?? () #34 0xb7cc2848 in __malloc_initialize_hook () from /lib/tls/libc.so.6 #35 0xb7cc2820 in __malloc_initialize_hook () from /lib/tls/libc.so.6 #36 0xb7cc2858 in __malloc_initialize_hook () from /lib/tls/libc.so.6 #37 0x00000004 in ?? () #38 0xb7cc0ff4 in ?? () from /lib/tls/libc.so.6 #39 0xb7cc2820 in __malloc_initialize_hook () from /lib/tls/libc.so.6 #40 0xfffffff0 in ?? () #41 0x00000038 in ?? () #42 0xb7bf861c in malloc () from /lib/tls/libc.so.6 #43 0xb7cc2820 in __malloc_initialize_hook () from /lib/tls/libc.so.6 #44 0x00000038 in ?? () #45 0xb7cc0ff4 in ?? () from /lib/tls/libc.so.6 #46 0x00000038 in ?? () #47 0x00000040 in ?? () #48 0xbfffce14 in ?? () #49 0x08129a1a in emacs_blocked_malloc (size=1886221359) at alloc.c:737 Previous frame inner to this frame (corrupt stack?) I'm really not used at C debugging and don't really know how to get more info, symbols, etc., but if you have a few instructions you would like me to follow, don't hesitate to ask. Does this problem still persist? While I cannot reproduce it either, the reporter might consider trying GCC CFLAGS options, eg. -march=i686 -O2 would be safe. The error looks similar to the -O3 failures with recent GCCs. (In reply to comment #3) > Does this problem still persist? I've just tried again (emacs-21.4-r3, sandbox-1.2.18.1, gcc-4.1.1, with "usersandbox" in FEATURES and "leim" in USE), and now it works fine. I will let you change resolution (seems i don't have rights to do it myself). > While I cannot reproduce it either, the reporter might consider trying GCC > CFLAGS options, eg. -march=i686 -O2 would be safe. I had tried that at the time of my initial report. The failure log was with CFLAGS="-pipe" btw, and i had also tried various middle ground flags like "-march=686 -02 -pipe". So we'll probably never now what was happening... Thanks for replying back. |