4:25 p.m.
Hello,
I'm building xemacs 21.5.21 with gcc version 3.2 20020903 (Red Hat
Linux 8.0 3.2-7)
Using ./configure --prefix=/usr/local/xemacs-21.5 --enable-mule
It compiles until it bootstraps xemacs:
./xemacs -nd -no-packages -batch -l
/home/alexm/src/xemacs-21.5.21/src/../lisp/update-elc.el
make[1]: *** [NEEDTODUMP] Segmentation fault (core dumped)
make[1]: Leaving directory `/home/alexm/src/xemacs-21.5.21/src'
(gdb) alexm＠derby:~/src/xemacs-21.5.21$ gdb -c src/core.18371 src/xemacs
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./xemacs -nd -no-packages -batch -l
/home/alexm/src/xemacs-21.5.21/src/../lisp/'.
Program terminated with signal 11, Segmentation fault.
#0 0x081b1e8f in set_lookup_table (ptr=0xb7a4a800, ph=0x83fb6b0)
at mc-alloc.c:531
531 LEVEL2 (l2, L2_INDEX (ptr)) = ph;
(gdb) bt
#0 0x081b1e8f in set_lookup_table (ptr=0xb7a4a800, ph=0x83fb6b0)
at mc-alloc.c:531
#1 0x081b1fd2 in add_pages_to_lookup_table (ph=0x83fb6b0, n_pages=33)
at mc-alloc.c:604
#2 0x081b2a94 in split_page (ph=0x83fb6b0, n_pages=33) at mc-alloc.c:1149
#3 0x081b2c5c in expand_heap (needed_pages=33) at mc-alloc.c:1214
#4 0x081b3084 in allocate_new_page (plh=0x83c42e0, size=65652, managed=1)
at mc-alloc.c:1406
#5 0x081b314e in mc_alloc_1 (size=65652, managed=1) at mc-alloc.c:1433
#6 0x081b31df in mc_alloc (size=65652) at mc-alloc.c:1461
#7 0x0808b34c in alloc_lrecord (size=65652, implementation=0x82a88e0)
at alloc.c:604
#8 0x0808beac in make_vector_internal (sizei=16411) at alloc.c:1613
#9 0x0808bed1 in make_vector (length=16411, object=1) at alloc.c:1627
#10 0x0822f32e in init_symbols_once_early () at symbols.c:3313
#11 0x080db32f in xemacs_21_5_b21_i686_pc_linux (argc=6, argv=0xbffff514,
unused_envp=0x0, restart=0) at emacs.c:1412
#12 0x080dc507 in main (argc=6, argv=0xbffff514, unused_envp=0xbffff530)
at emacs.c:3064
#13 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
Please let me know if you need more information.
Thank you,
--alexm
5:22 p.m.
>>>>"AM" == Alexey Mahotkin
<squadette(a)gmail.com> writes:
AM>
/home/alexm/src/xemacs-21.5.21/src/../lisp/'. Program terminated
AM> with signal 11, Segmentation fault. #0 0x081b1e8f in
AM> set_lookup_table (ptr=0xb7a4a800, ph=0x83fb6b0) at mc-alloc.c:531
AM> 531 LEVEL2 (l2, L2_INDEX (ptr)) = ph;
This is a bug in the new allocator. I'll look into this. Meanwhile,
you can configure with `--disable-mc-alloc' to get a working XEmacs.
Thanks for reporting this!
--
Marcus
3:24 p.m.
New subject: [AC21.5] segfault during compilation
APPROVE COMMIT 21.5
NOTE: This patch has been committed.
>>>>"AM" == Alexey Mahotkin
<squadette(a)gmail.com> writes:
AM>
/home/alexm/src/xemacs-21.5.21/src/../lisp/'. Program terminated
AM> with signal 11, Segmentation fault. #0 0x081b1e8f in
AM> set_lookup_table (ptr=0xb7a4a800, ph=0x83fb6b0) at mc-alloc.c:531
AM> 531 LEVEL2 (l2, L2_INDEX (ptr)) = ph;
The cause of the problem is that the lookup table is not correctly
initialized. The segfault on x86-64 systems reported by Mike Fabian
may also be caused by this bug.
Alexey, could you please test if this patch really fixes your build
and report back? Thank you!
src/ChangeLog addition:
2005-09-14 Marcus Crestani <crestani(a)xemacs.org>
* mc-alloc.c (set_lookup_table): Adjust parameter to other memset
calls.
* mc-alloc.c (init_mc_allocator): Zero global allocator structure.
manual-mc-xemacs-21.5 source patch:
Diff command: cvs -q diff -u
Files affected: src/mc-alloc.c
Index: src/mc-alloc.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/mc-alloc.c,v
retrieving revision 1.3
diff -u -r1.3 mc-alloc.c
--- src/mc-alloc.c 15 May 2005 16:38:13 -0000 1.3
+++ src/mc-alloc.c 14 Sep 2005 13:26:07 -0000
＠＠ -521,7 +521,7 ＠＠
MC_MALLOCED_BYTES +=
malloced_storage_size (0, sizeof (level_2_lookup_tree), 0);
#endif
- memset (l2, 0, sizeof (level_2_lookup_tree));
+ memset (l2, '\0', sizeof (level_2_lookup_tree));
#ifdef USE_HASH_TABLE
LEVEL2_HASH_LINK (l2) = PTR_LOOKUP_TABLE (l1_index);
#endif
＠＠ -1689,6 +1689,8 ＠＠
init_mc_allocator (void)
{
int i;
+
+ memset (&mc_allocator_globals, '\0', sizeof (mc_allocator_globals_type));
for (i = 0; i < N_USED_PAGE_LISTS; i++)
{
--
Marcus
3:37 p.m.
New subject: [AC21.5] segfault during compilation
Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> writes:
- memset (l2, 0, sizeof (level_2_lookup_tree));
+ memset (l2, '\0', sizeof (level_2_lookup_tree));
This change will probably not fix any bug. In C, '\0' is another way
to spell 0, and in C++ '\0' will be cast to 0 anyway, since memset's
second argument is int.
Not that I'm against the change -- using '\0' makes the *intention* a
bit clearer -- but it should be applied with understanding that it
doesn't resolve any real problem.
+ memset (&mc_allocator_globals, '\0', sizeof
(mc_allocator_globals_type));
This shouldn't be necessary unless init_mc_allocator is called twice
(which it shouldn't be, judging by the comments and the code). A
global variable is 0-initialized by default and calling memset doesn't
accomplish anything.
Also note that in XEmacs you can spell the above memset as:
xzero (mc_allocator_globals);
4:56 p.m.
New subject: [AC21.5] segfault during compilation
>>>>"HN" == Hrvoje Niksic
<hniksic(a)xemacs.org> writes:
HN> This change will probably not fix any bug.
In C, '\0' is another
HN> way to spell 0, and in C++ '\0' will be cast to 0 anyway, since
HN> memset's second argument is int.
HN> Not that I'm against the change -- using '\0' makes the
HN> *intention* a bit clearer -- but it should be applied with
HN> understanding that it doesn't resolve any real problem.
Right, this part of the patch does not address the problem. I just
stumbled across this memset call and adjusted it to the others.
HN>> + memset (&mc_allocator_globals, '\0', sizeof
HN>> (mc_allocator_globals_type));
HN> This shouldn't be necessary unless init_mc_allocator is called
HN> twice (which it shouldn't be, judging by the comments and the
HN> code). A global variable is 0-initialized by default and calling
HN> memset doesn't accomplish anything.
An uninitialized lookup table is the only thing I can currently think
of that may cause the reported failure. Although, I was quite
surprised that this bug didn't hit earlier and more often. I'll keep
on investigating. Do you want me to revert this change?
--
Marcus
5:17 p.m.
New subject: [AC21.5] segfault during compilation
Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> writes:
HN>> + memset (&mc_allocator_globals, '\0', sizeof
HN>> (mc_allocator_globals_type));
HN> This shouldn't be necessary unless init_mc_allocator is called
HN> twice (which it shouldn't be, judging by the comments and the
HN> code). A global variable is 0-initialized by default and calling
HN> memset doesn't accomplish anything.
An uninitialized lookup table is the only thing I can currently
think of that may cause the reported failure. Although, I was quite
surprised that this bug didn't hit earlier and more often. I'll
keep on investigating. Do you want me to revert this change?
It doesn't hurt to have it in, so let's wait for feedback. If the
change doesn't help (which I think it won't because of the reasons
stated above), then revert it.
Maybe it would help for Alexey to look at other local variables?
5:42 p.m.
New subject: [AC21.5] segfault during compilation
Hrvoje Niksic <hniksic(a)xemacs.org> wrote:
Maybe it would help for Alexey to look at other local variables?
Dumping out the contents of l2 would certainly be useful. Given
what Hrvoje said, this looks more like some kind of memory corruption
bug (or maybe a gcc compiler issue, given how buggy it can sometimes be
-- what compiler flags were used?).
--
Darryl Okahata
darrylo(a)soco.agilent.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.
3:40 p.m.
New subject: [AC21.5] segfault during compilation
Marcus,
no change at all. I did more investigation (533 is because of
additional debugging code):
#0 0x081b1e9d in set_lookup_table (ptr=0xb7a4a800, ph=0x83fb6b0)
at mc-alloc.c:533
533 LEVEL2 (l2, L2_INDEX (ptr)) = ph;
(gdb) print l2
$1 = (struct level_2_lookup_tree *) 0x3
I think it should tell you something :)
On 9/14/05, Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> wrote:
APPROVE COMMIT 21.5
NOTE: This patch has been committed.
>>>>>"AM" == Alexey Mahotkin <squadette(a)gmail.com>
writes:
AM> /home/alexm/src/xemacs-21.5.21/src/../lisp/'. Program terminated
AM> with signal 11, Segmentation fault. #0 0x081b1e8f in
AM> set_lookup_table (ptr=0xb7a4a800, ph=0x83fb6b0) at mc-alloc.c:531
AM> 531 LEVEL2 (l2, L2_INDEX (ptr)) = ph;
The cause of the problem is that the lookup table is not correctly
initialized. The segfault on x86-64 systems reported by Mike Fabian
may also be caused by this bug.
Alexey, could you please test if this patch really fixes your build
and report back? Thank you!
src/ChangeLog addition:
2005-09-14 Marcus Crestani <crestani(a)xemacs.org>
* mc-alloc.c (set_lookup_table): Adjust parameter to other memset
calls.
* mc-alloc.c (init_mc_allocator): Zero global allocator structure.
manual-mc-xemacs-21.5 source patch:
Diff command: cvs -q diff -u
Files affected: src/mc-alloc.c
Index: src/mc-alloc.c
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/mc-alloc.c,v
retrieving revision 1.3
diff -u -r1.3 mc-alloc.c
--- src/mc-alloc.c 15 May 2005 16:38:13 -0000 1.3
+++ src/mc-alloc.c 14 Sep 2005 13:26:07 -0000
＠＠ -521,7 +521,7 ＠＠
MC_MALLOCED_BYTES +=
malloced_storage_size (0, sizeof (level_2_lookup_tree), 0);
#endif
- memset (l2, 0, sizeof (level_2_lookup_tree));
+ memset (l2, '\0', sizeof (level_2_lookup_tree));
#ifdef USE_HASH_TABLE
LEVEL2_HASH_LINK (l2) = PTR_LOOKUP_TABLE (l1_index);
#endif
＠＠ -1689,6 +1689,8 ＠＠
init_mc_allocator (void)
{
int i;
+
+ memset (&mc_allocator_globals, '\0', sizeof (mc_allocator_globals_type));
for (i = 0; i < N_USED_PAGE_LISTS; i++)
{
--
Marcus
3:51 p.m.
New subject: [AC21.5] segfault during compilation
On 9/14/05, Alexey Mahotkin <squadette(a)gmail.com> wrote:
Marcus,
seems like my inner PHB is starting to take over me. However, I
suddenly remembered about the valgrind. Here is the output:
alexm＠derby:~/src/xemacs-21.5.21$ valgrind src/xemacs -nd -no-packages
-batch -l /home/alexm/src/xemacs-21.5.21/src/../lisp/update-elc.el
==17813== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==17813== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==17813== Using valgrind-2.0.0, a program supervision framework for x86-linux.
==17813== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==17813== Estimated CPU clock rate is 1661 MHz
==17813== For more details, rerun with: -v
==17813==
==17813== Invalid read of size 4
==17813== at 0x81B3694: mc_free (mc-alloc.c:1631)
==17813== by 0x808B65F: free_lrecord (alloc.c:645)
==17813== by 0x81D108C: free_opaque_ptr (opaque.c:187)
==17813== by 0x80E2F3A: condition_bind_unwind (eval.c:1761)
==17813== Address 0x3CB5BAD4 is not stack'd, malloc'd or free'd
Segmentation fault (core dumped)
no change at all. I did more investigation (533 is because of
additional debugging code):
#0 0x081b1e9d in set_lookup_table (ptr=0xb7a4a800, ph=0x83fb6b0)
at mc-alloc.c:533
533 LEVEL2 (l2, L2_INDEX (ptr)) = ph;
(gdb) print l2
$1 = (struct level_2_lookup_tree *) 0x3
I think it should tell you something :)
On 9/14/05, Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> wrote:
> APPROVE COMMIT 21.5
>
> NOTE: This patch has been committed.
>
> >>>>>"AM" == Alexey Mahotkin <squadette(a)gmail.com>
writes:
> AM> /home/alexm/src/xemacs-21.5.21/src/../lisp/'. Program terminated
> AM> with signal 11, Segmentation fault. #0 0x081b1e8f in
> AM> set_lookup_table (ptr=0xb7a4a800, ph=0x83fb6b0) at mc-alloc.c:531
> AM> 531 LEVEL2 (l2, L2_INDEX (ptr)) = ph;
>
> The cause of the problem is that the lookup table is not correctly
> initialized. The segfault on x86-64 systems reported by Mike Fabian
> may also be caused by this bug.
>
> Alexey, could you please test if this patch really fixes your build
> and report back? Thank you!
>
>
> src/ChangeLog addition:
>
> 2005-09-14 Marcus Crestani <crestani(a)xemacs.org>
>
> * mc-alloc.c (set_lookup_table): Adjust parameter to other memset
> calls.
> * mc-alloc.c (init_mc_allocator): Zero global allocator structure.
>
>
> manual-mc-xemacs-21.5 source patch:
> Diff command: cvs -q diff -u
> Files affected: src/mc-alloc.c
>
> Index: src/mc-alloc.c
> ===================================================================
> RCS file: /pack/xemacscvs/XEmacs/xemacs/src/mc-alloc.c,v
> retrieving revision 1.3
> diff -u -r1.3 mc-alloc.c
> --- src/mc-alloc.c 15 May 2005 16:38:13 -0000 1.3
> +++ src/mc-alloc.c 14 Sep 2005 13:26:07 -0000
> ＠＠ -521,7 +521,7 ＠＠
> MC_MALLOCED_BYTES +=
> malloced_storage_size (0, sizeof (level_2_lookup_tree), 0);
> #endif
> - memset (l2, 0, sizeof (level_2_lookup_tree));
> + memset (l2, '\0', sizeof (level_2_lookup_tree));
> #ifdef USE_HASH_TABLE
> LEVEL2_HASH_LINK (l2) = PTR_LOOKUP_TABLE (l1_index);
> #endif
> ＠＠ -1689,6 +1689,8 ＠＠
> init_mc_allocator (void)
> {
> int i;
> +
> + memset (&mc_allocator_globals, '\0', sizeof
(mc_allocator_globals_type));
>
> for (i = 0; i < N_USED_PAGE_LISTS; i++)
> {
>
> --
> Marcus
>
--alexm
12:30 p.m.
New subject: [AC21.5] segfault during compilation
Alexey,
thanks for your investigation, I could use more of it on that bug.
>>>>"AM" == Alexey Mahotkin
<squadette(a)gmail.com> writes:
AM> #0 0x081b1e9d in set_lookup_table
(ptr=0xb7a4a800, ph=0x83fb6b0)
AM> at mc-alloc.c:533
AM> 533 LEVEL2 (l2, L2_INDEX (ptr)) = ph;
AM> (gdb) print l2
AM> $1 = (struct level_2_lookup_tree *) 0x3
This is probably a memory corruption bug, debugging these is a real
pain in the ass... However, you should be able to set a watchpoint on
this slot of the lookup table and see what writes the 0x3 to it.
Something like this should work:
First, figure out the address of the lookup table slot:
(gdb) print &mc_allocator_globals.ptr_lookup_table[l1_index]
$1 = (level_2_lookup_tree **) 0xXXXXXXXX
Then, set a watchpoint to this address:
(gdb) watch *(int *) 0xXXXXXXXX
And re-start the program from the beginning:
(gdb) run
This should hopefully lead to
Hardware watchpoint 1: *(int *) 0xXXXXXXXX
Old value = <something>
New value = 3
and a backtrace to the wrongdoer.
AM> ==17813== Invalid read of size 4
AM> ==17813== at 0x81B3694: mc_free (mc-alloc.c:1631)
AM> ==17813== by 0x808B65F: free_lrecord (alloc.c:645)
AM> ==17813== by 0x81D108C: free_opaque_ptr (opaque.c:187)
AM> ==17813== by 0x80E2F3A: condition_bind_unwind (eval.c:1761)
AM> ==17813== Address 0x3CB5BAD4 is not stack'd, malloc'd or free'd
AM> Segmentation fault (core dumped)
The invalid read is maybe related to the above memory corruption and
will hopefully go away once the above is fixed. It hits the assert
statement in line 1631. Since this is a complex one, it is
interesting to split it up and see what part of it causes the invalid
access:
--- mc-alloc.c 14 Sep 2005 14:24:30 -0000 1.4
+++ mc-alloc.c 15 Sep 2005 11:12:22 -0000
＠＠ -1628,7 +1628,9 ＠＠
mc_free (void *ptr)
{
page_header *ph = get_page_header (ptr);
- assert (!PH_ON_FREE_LIST_P (ph));
+ assert (ph);
+ assert (PH_PLH (ph));
+ assert (PLH_LIST_TYPE (PH_PLH (ph)) != FREE_LIST);
remove_cell (ptr, ph);
Attaching to the debugger after valgrind reports the error and looking
at `*ph' and `*ph->plh' might also be useful (`--db-attach=yes').
Thanks again for your help!
--
Marcus
12:43 p.m.
New subject: [AC21.5] segfault during compilation
Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> writes:
First, figure out the address of the lookup table slot:
(gdb) print &mc_allocator_globals.ptr_lookup_table[l1_index]
$1 = (level_2_lookup_tree **) 0xXXXXXXXX
Then, set a watchpoint to this address:
(gdb) watch *(int *) 0xXXXXXXXX
I think "watch *$1" should also work -- that's what those
dollar-prefixed numbers are for.
2:02 p.m.
New subject: [AC21.5] segfault during compilation
On 9/15/05, Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> wrote:
thanks for your investigation, I could use more of it on that bug.
>>>>>"AM" == Alexey Mahotkin <squadette(a)gmail.com>
writes:
AM> #0 0x081b1e9d in set_lookup_table (ptr=0xb7a4a800, ph=0x83fb6b0)
AM> at mc-alloc.c:533
AM> 533 LEVEL2 (l2, L2_INDEX (ptr)) = ph;
AM> (gdb) print l2
AM> $1 = (struct level_2_lookup_tree *) 0x3
This is probably a memory corruption bug, debugging these is a real
pain in the ass... However, you should be able to set a watchpoint on
this slot of the lookup table and see what writes the 0x3 to it.
Something like this should work:
First, figure out the address of the lookup table slot:
(gdb) print &mc_allocator_globals.ptr_lookup_table[l1_index]
$1 = (level_2_lookup_tree **) 0xXXXXXXXX
#0 0x081b1e8f in set_lookup_table (ptr=0xb7a4a800, ph=0x83fb6b0)
at mc-alloc.c:531
531 LEVEL2 (l2, L2_INDEX (ptr)) = ph;
(gdb) print &mc_allocator_globals.ptr_lookup_table[l1_index]
$1 = (struct level_2_lookup_tree **) 0x83c6b7c
(gdb) watch *$1
Hardware watchpoint 1: *$1
(gdb) run
Starting program: /home/alexm/src/xemacs-21.5.21/src/xemacs
Hardware watchpoint 1: *$1
---Type <return> to continue, or q <return> to quit---
Old value = (struct level_2_lookup_tree *) 0x0
New value = (struct level_2_lookup_tree *) 0x3
init_mc_allocator () at mc-alloc.c:1734
1734 PLH_FIRST (plh) = 0;
(gdb) bt
#0 init_mc_allocator () at mc-alloc.c:1734
#1 0x080daaaf in xemacs_21_5_b21_i686_pc_linux (argc=1, argv=0xbffff584,
unused_envp=0x0, restart=0) at emacs.c:921
#2 0x080dc507 in main (argc=1, argv=0xbffff584, unused_envp=0xbffff58c)
at emacs.c:3064
#3 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
I think this could also be helpful:
(gdb) print i
$2 = 2
(gdb) print plh
$3 = (struct page_list_header *) 0x83c6b78
(gdb) print *plh
$4 = {list_type = FREE_LIST, size = 3, first = 0x0, last = 0x0,
mark_bit_free_list = 0x0, page_count = 0, used_cells = 0, used_space = 0,
total_cells = 0, total_space = 0}
--alexm
11:17 p.m.
New subject: [AC21.5] segfault during compilation
>>>>"AM" == Alexey Mahotkin
<squadette(a)gmail.com> writes:
AM> Old value = (struct level_2_lookup_tree
*) 0x0
AM> New value = (struct level_2_lookup_tree *) 0x3
AM> init_mc_allocator () at mc-alloc.c:1734
AM> 1734 PLH_FIRST (plh) = 0;
AM> (gdb) bt
AM> #0 init_mc_allocator () at mc-alloc.c:1734
Seems that the struct mc_allocator_globals is somehow corrupted:
Looping over the free_heap_pages array and setting initial values
writes into the ptr_lookup_table. Both arrays are kept in the same
struct. Does the structure of mc_allocator_globals look similar to
this (before actually running XEmacs)?
(gdb) print mc_allocator_globals
$1 = {heap_size = 0,
heap_sections = {{real_start = 0x0, real_size = 0, start = 0x0,
n_pages = 0} <repeats 768 times>}, n_heap_sections = 0,
used_heap_pages = {{list_type = USED_LIST, size = 0, first = 0x0,
last = 0x0, mark_bit_free_list = 0x0, page_count = 0, used_cells = 0,
used_space = 0, total_cells = 0, total_space = 0} <repeats 256 times>},
unmanaged_heap_pages = {{list_type = USED_LIST, size = 0, first = 0x0,
last = 0x0, mark_bit_free_list = 0x0, page_count = 0, used_cells = 0,
used_space = 0, total_cells = 0, total_space = 0} <repeats 256 times>},
free_heap_pages = {{list_type = USED_LIST, size = 0, first = 0x0,
last = 0x0, mark_bit_free_list = 0x0, page_count = 0, used_cells = 0,
used_space = 0, total_cells = 0, total_space = 0} <repeats 60 times>},
ptr_lookup_table = {0x0 <repeats 2048 times>},
page_header_free_list = 0x0,
malloced_bytes = 0}
How does it look like when the segfault occurs?
--
Marcus
2:08 p.m.
New subject: [AC21.5] segfault during compilation
On 9/15/05, Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> wrote:
- assert (!PH_ON_FREE_LIST_P (ph));
+ assert (ph);
+ assert (PH_PLH (ph));
It breaks here.
+ assert (PLH_LIST_TYPE (PH_PLH (ph)) != FREE_LIST);
remove_cell (ptr, ph);
Attaching to the debugger after valgrind reports the error and looking
at `*ph' and `*ph->plh' might also be useful (`--db-attach=yes').
--gdb-attach=yes, btw. The environment is quite different due to
valgrind, but here it is:
(gdb) bt
#0 vg_do_syscall3 (syscallno=4294966784, arg1=15598, arg2=0, arg3=0)
at vg_mylibc.c:92
#1 0x00003cee in ?? ()
#2 0x081b36ae in mc_free (ptr=0xb5b9a840) at mc-alloc.c:1632
#3 0x0808b660 in free_lrecord (lrecord=-1246123968) at alloc.c:645
#4 0x081d10c1 in free_opaque_ptr (ptr=-1246123968) at opaque.c:187
#5 0x080e2f3b in condition_bind_unwind (loser=-1246061776) at eval.c:1761
#6 0x080eac92 in unbind_to_hairy (count=1) at eval.c:6065
#7 0x080eabe2 in unbind_to_1 (count=1, value=-1246470120) at eval.c:6017
#8 0x080e3803 in call_with_condition_handler (
handler=0x80e892a <flagged_a_squirmer>, handler_arg=-1246123976,
fun=0x80e8998 <call_trapping_problems_2>, arg=-1246123976) at eval.c:2135
#9 0x080e89ed in call_trapping_problems_1 (opaque=-1246123976) at eval.c:4891
#10 0x080e2bdd in internal_catch (tag=-1246124032,
func=0x80e89d2 <call_trapping_problems_1>, arg=-1246123976,
threw=0xbffff07c, thrown_tag=0xbffff088, backtrace_before_throw=0xbffff080)
at eval.c:1530
#11 0x080e8e01 in call_trapping_problems (warning_class=-1246414952,
warning_string=0x0, flags=98311, problem=0x0,
fun=0x80e9036 <va_call_trapping_problems_1>, arg=0xbffff190) at eval.c:5164
#12 0x080e96fb in call_with_suspended_errors (
fun=0x82238ba <call_validate_method>, retval=-1246470144,
class_=-1246414952, errb=
---Type <return> to continue, or q <return> to quit---
{really_unlikely_name_to_have_accidentally_in_a_non_errb_structure
= 42}, nargs=2) at eval.c:5329
#13 0x0822397c in check_valid_instantiator (instantiator=-1246217364,
meths=0xb5b8d52c, errb=
{really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 42})
at specifier.c:1203
#14 0x08223b37 in check_valid_inst_list (inst_list=-1246061860,
meths=0xb5b8d52c, errb=
{really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 42})
at specifier.c:1261
#15 0x08223c2f in Fvalid_inst_list_p (inst_list=-1246061860, type=-1246416896)
at specifier.c:1285
#16 0x0822646c in set_specifier_fallback (specifier=-1246221104,
fallback=-1246061860) at specifier.c:2427
#17 0x08163d97 in allocate_glyph (type=GLYPH_BUFFER,
after_change=0x81fa440 <redisplay_glyph_changed>) at glyphs.c:3841
#18 0x08169df0 in complex_vars_of_glyphs () at glyphs.c:5569
#19 0x080db8f5 in xemacs_21_5_b21_i686_pc_linux (argc=6, argv=0xbffff474,
unused_envp=0x0, restart=0) at emacs.c:2380
#20 0x080dc507 in main (argc=6, argv=0xbffff474, unused_envp=0xbffff490)
at emacs.c:3064
#21 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
(gdb)
(gdb) up
#1 0x00003cee in ?? ()
(gdb) up
#2 0x081b36ae in mc_free (ptr=0xb5b9a840) at mc-alloc.c:1632
1632 assert (PH_PLH (ph));
(gdb) print *ph
Cannot access memory at address 0x3cb5bacc
(gdb) print ph
$1 = (struct page_header *) 0x3cb5bacc
--alexm
6:40 p.m.
New subject: [AC21.5] segfault during compilation
On 9/15/05, Alexey Mahotkin <squadette(a)gmail.com> wrote:
Btw,
I tried compilation on another machine that once was an identical twin
to derby, and it runs fine there. Two years passed, and derby was
used as a development server, and who know what kind of libraries were
installed there. However, the gcc/libc are the same.
So, this could be a problem with this particular installation We may
forget it all if you wish; however I could try more tests/patches if
you want to make sure.
--alexm
11:21 p.m.
New subject: [AC21.5] segfault during compilation
>>>>"AM" == Alexey Mahotkin
<squadette(a)gmail.com> writes:
AM> #2 0x081b36ae in mc_free
(ptr=0xb5b9a840) at mc-alloc.c:1632
AM> 1632 assert (PH_PLH (ph));
AM> (gdb) print *ph
AM> Cannot access memory at address 0x3cb5bacc
AM> (gdb) print ph
AM> $1 = (struct page_header *) 0x3cb5bacc
If the ptr_lookup_table is corrupted the allocator is no longer able
to map heap pointers to page headers. This problem will go away as
soon as we have fixed the memory corruption.
--
Marcus
6:28 p.m.
New subject: [AC21.5] segfault during compilation
On 9/15/05, Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> wrote:
This is probably a memory corruption bug, debugging these is a real
pain in the ass... However, you should be able to set a watchpoint on
this slot of the lookup table and see what writes the 0x3 to it.
Btw, this seems to be NOT a compiler bug. I recompiled it with -O0
and nothing changed.
Marcus, if our theory is that it is a memory corruption bug -- when
you run valgrind on your machine -- does it say that xemacs is clean?
--alexm
11:23 p.m.
New subject: [AC21.5] segfault during compilation
>>>>"AM" == Alexey Mahotkin
<squadette(a)gmail.com> writes:
AM> Marcus, if our theory is that it is a
memory corruption bug --
AM> when you run valgrind on your machine -- does it say that xemacs
AM> is clean?
Valgrind complains about some Lstream-related invalid reads, but
nothing concerns the new allocator. You'll probably see the same when
you run valgrind on the other system you mentioned where XEmacs works.
--
Marcus
4:38 p.m.
New subject: [AC21.5] segfault during compilation
Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> wrote:
Valgrind complains about some Lstream-related invalid reads, but
nothing concerns the new allocator. You'll probably see the same when
you run valgrind on the other system you mentioned where XEmacs works.
Since this is so repeatable (and XEmacs hasn't even been dumped,
yet ;-), Hrvoje's watchpoint suggestion is the best way to debug this.
[ Of course, I'm assuming that hardware watchpoints are available, and
tbey should be, since we're talking 32-bit x86 linux. ]
--
Darryl Okahata
darrylo(a)soco.agilent.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.
10:03 a.m.
New subject: [AC21.5] segfault during compilation
>>>> "Marcus" == Marcus Crestani
<crestani(a)informatik.uni-tuebingen.de> writes:
Marcus> Valgrind complains about some Lstream-related invalid
Marcus> reads, but nothing concerns the new allocator.
Could you give me details on those invalid reads? They might be a
lead on some crashes in Mule.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
1:52 p.m.
New subject: [AC21.5] segfault during compilation
>>>>"SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
SJT> Could you give me details on those
invalid reads? They might be
SJT> a lead on some crashes in Mule.
$ valgrind -v ./xemacs -vanilla -kill
[...]
==1219== ERROR SUMMARY: 52 errors from 10 contexts (suppressed: 95 from 2)
==1219==
==1219== 1 errors in context 1 of 10:
==1219== Invalid read of size 1
==1219== at 0x1B906328: strlen (in /usr/lib/valgrind/vgpreload_memcheck.so)
==1219== by 0x810CBEB: dfc_external_data_len (text.h:287)
==1219== by 0x808E4DC: build_ext_string (alloc.c:2972)
==1219== by 0x81A5CD1: Fset_current_locale (intl.c:92)
==1219== by 0x80EAB86: Ffuncall (eval.c:3847)
==1219== by 0x809F6CB: execute_optimized_program (bytecode.c:823)
==1219== by 0x80F2418: funcall_compiled_function (eval.c:3457)
==1219== by 0x80EAE62: Ffuncall (eval.c:3886)
==1219== by 0x80E7849: Fcall_with_condition_handler (eval.c:2101)
==1219== by 0x81A5D3B: init_intl (intl.c:174)
==1219== by 0x80DF74A: xemacs_21_5_b22_i686_pc_linux (emacs.c:2500)
==1219== by 0x80E02F1: main (emacs.c:3064)
==1219== Address 0x1C6BE4D0 is 0 bytes inside a block of size 12 free'd
==1219== at 0x1B9057CD: free (in /usr/lib/valgrind/vgpreload_memcheck.so)
==1219== by 0x1BF511C6: setlocale (in /lib/tls/libc.so.6)
==1219== by 0x81A5C6F: Fset_current_locale (intl.c:79)
==1219== by 0x80EAB86: Ffuncall (eval.c:3847)
==1219== by 0x809F6CB: execute_optimized_program (bytecode.c:823)
==1219== by 0x80F2418: funcall_compiled_function (eval.c:3457)
==1219== by 0x80EAE62: Ffuncall (eval.c:3886)
==1219== by 0x80E7849: Fcall_with_condition_handler (eval.c:2101)
==1219== by 0x81A5D3B: init_intl (intl.c:174)
==1219== by 0x80DF74A: xemacs_21_5_b22_i686_pc_linux (emacs.c:2500)
==1219== by 0x80E02F1: main (emacs.c:3064)
==1219==
==1219== 2 errors in context 2 of 10:
==1219== Conditional jump or move depends on uninitialised value(s)
==1219== at 0x82AA336: xm_update_label (lwlib-Xm.c:222)
==1219== by 0x82AA60B: xm_safe_update_label (lwlib-Xm.c:314)
==1219== by 0x82AAC5F: xm_update_one_widget (lwlib-Xm.c:854)
==1219== by 0x82B3FA7: xlw_update_tab_control (lwlib-Xlw.c:458)
==1219== by 0x82B4207: xlw_update_one_widget (lwlib-Xlw.c:578)
==1219== by 0x82A88CA: set_one_value (lwlib.c:718)
==1219== by 0x82A893F: update_one_widget_instance (lwlib.c:742)
==1219== by 0x82A8BB0: initialize_widget_instance (lwlib.c:821)
==1219== by 0x82A8FA4: lw_make_widget (lwlib.c:974)
==1219== by 0x82A9015: lw_create_widget (lwlib.c:989)
==1219== by 0x827D05E: x_widget_instantiate (glyphs-x.c:2468)
==1219== by 0x827D838: x_tab_control_instantiate (glyphs-x.c:2678)
==1219==
==1219== 2 errors in context 3 of 10:
==1219== Invalid read of size 1
==1219== at 0x1B906642: memcpy (in /usr/lib/valgrind/vgpreload_memcheck.so)
==1219== by 0x81BCE32: fixed_buffer_reader (lstream.c:1468)
==1219== by 0x81BB78C: Lstream_raw_read (lstream.c:628)
==1219== by 0x81BB84A: Lstream_read_more (lstream.c:648)
==1219== by 0x81BBA2E: Lstream_read_1 (lstream.c:714)
==1219== by 0x81BBADA: Lstream_read (lstream.c:743)
==1219== by 0x8250F2B: dfc_convert_to_internal_format (text.c:4435)
==1219== by 0x808E431: make_ext_string (alloc.c:2948)
==1219== by 0x808E4F6: build_ext_string (alloc.c:2972)
==1219== by 0x81A5CD1: Fset_current_locale (intl.c:92)
==1219== by 0x80EAB86: Ffuncall (eval.c:3847)
==1219== by 0x809F6CB: execute_optimized_program (bytecode.c:823)
==1219== Address 0x1C6BE4D7 is 7 bytes inside a block of size 12 free'd
==1219== at 0x1B9057CD: free (in /usr/lib/valgrind/vgpreload_memcheck.so)
==1219== by 0x1BF511C6: setlocale (in /lib/tls/libc.so.6)
==1219== by 0x81A5C6F: Fset_current_locale (intl.c:79)
==1219== by 0x80EAB86: Ffuncall (eval.c:3847)
==1219== by 0x809F6CB: execute_optimized_program (bytecode.c:823)
==1219== by 0x80F2418: funcall_compiled_function (eval.c:3457)
==1219== by 0x80EAE62: Ffuncall (eval.c:3886)
==1219== by 0x80E7849: Fcall_with_condition_handler (eval.c:2101)
==1219== by 0x81A5D3B: init_intl (intl.c:174)
==1219== by 0x80DF74A: xemacs_21_5_b22_i686_pc_linux (emacs.c:2500)
==1219== by 0x80E02F1: main (emacs.c:3064)
==1219==
==1219== 2 errors in context 4 of 10:
==1219== Invalid read of size 1
==1219== at 0x1B90663C: memcpy (in /usr/lib/valgrind/vgpreload_memcheck.so)
==1219== by 0x81BCE32: fixed_buffer_reader (lstream.c:1468)
==1219== by 0x81BB78C: Lstream_raw_read (lstream.c:628)
==1219== by 0x81BB84A: Lstream_read_more (lstream.c:648)
==1219== by 0x81BBA2E: Lstream_read_1 (lstream.c:714)
==1219== by 0x81BBADA: Lstream_read (lstream.c:743)
==1219== by 0x8250F2B: dfc_convert_to_internal_format (text.c:4435)
==1219== by 0x808E431: make_ext_string (alloc.c:2948)
==1219== by 0x808E4F6: build_ext_string (alloc.c:2972)
==1219== by 0x81A5CD1: Fset_current_locale (intl.c:92)
==1219== by 0x80EAB86: Ffuncall (eval.c:3847)
==1219== by 0x809F6CB: execute_optimized_program (bytecode.c:823)
==1219== Address 0x1C6BE4D8 is 8 bytes inside a block of size 12 free'd
==1219== at 0x1B9057CD: free (in /usr/lib/valgrind/vgpreload_memcheck.so)
==1219== by 0x1BF511C6: setlocale (in /lib/tls/libc.so.6)
==1219== by 0x81A5C6F: Fset_current_locale (intl.c:79)
==1219== by 0x80EAB86: Ffuncall (eval.c:3847)
==1219== by 0x809F6CB: execute_optimized_program (bytecode.c:823)
==1219== by 0x80F2418: funcall_compiled_function (eval.c:3457)
==1219== by 0x80EAE62: Ffuncall (eval.c:3886)
==1219== by 0x80E7849: Fcall_with_condition_handler (eval.c:2101)
==1219== by 0x81A5D3B: init_intl (intl.c:174)
==1219== by 0x80DF74A: xemacs_21_5_b22_i686_pc_linux (emacs.c:2500)
==1219== by 0x80E02F1: main (emacs.c:3064)
==1219==
==1219== 2 errors in context 5 of 10:
==1219== Invalid read of size 1
==1219== at 0x1B906636: memcpy (in /usr/lib/valgrind/vgpreload_memcheck.so)
==1219== by 0x81BCE32: fixed_buffer_reader (lstream.c:1468)
==1219== by 0x81BB78C: Lstream_raw_read (lstream.c:628)
==1219== by 0x81BB84A: Lstream_read_more (lstream.c:648)
==1219== by 0x81BBA2E: Lstream_read_1 (lstream.c:714)
==1219== by 0x81BBADA: Lstream_read (lstream.c:743)
==1219== by 0x8250F2B: dfc_convert_to_internal_format (text.c:4435)
==1219== by 0x808E431: make_ext_string (alloc.c:2948)
==1219== by 0x808E4F6: build_ext_string (alloc.c:2972)
==1219== by 0x81A5CD1: Fset_current_locale (intl.c:92)
==1219== by 0x80EAB86: Ffuncall (eval.c:3847)
==1219== by 0x809F6CB: execute_optimized_program (bytecode.c:823)
==1219== Address 0x1C6BE4D9 is 9 bytes inside a block of size 12 free'd
==1219== at 0x1B9057CD: free (in /usr/lib/valgrind/vgpreload_memcheck.so)
==1219== by 0x1BF511C6: setlocale (in /lib/tls/libc.so.6)
==1219== by 0x81A5C6F: Fset_current_locale (intl.c:79)
==1219== by 0x80EAB86: Ffuncall (eval.c:3847)
==1219== by 0x809F6CB: execute_optimized_program (bytecode.c:823)
==1219== by 0x80F2418: funcall_compiled_function (eval.c:3457)
==1219== by 0x80EAE62: Ffuncall (eval.c:3886)
==1219== by 0x80E7849: Fcall_with_condition_handler (eval.c:2101)
==1219== by 0x81A5D3B: init_intl (intl.c:174)
==1219== by 0x80DF74A: xemacs_21_5_b22_i686_pc_linux (emacs.c:2500)
==1219== by 0x80E02F1: main (emacs.c:3064)
==1219==
==1219== 2 errors in context 6 of 10:
==1219== Invalid read of size 1
==1219== at 0x1B906630: memcpy (in /usr/lib/valgrind/vgpreload_memcheck.so)
==1219== by 0x81BCE32: fixed_buffer_reader (lstream.c:1468)
==1219== by 0x81BB78C: Lstream_raw_read (lstream.c:628)
==1219== by 0x81BB84A: Lstream_read_more (lstream.c:648)
==1219== by 0x81BBA2E: Lstream_read_1 (lstream.c:714)
==1219== by 0x81BBADA: Lstream_read (lstream.c:743)
==1219== by 0x8250F2B: dfc_convert_to_internal_format (text.c:4435)
==1219== by 0x808E431: make_ext_string (alloc.c:2948)
==1219== by 0x808E4F6: build_ext_string (alloc.c:2972)
==1219== by 0x81A5CD1: Fset_current_locale (intl.c:92)
==1219== by 0x80EAB86: Ffuncall (eval.c:3847)
==1219== by 0x809F6CB: execute_optimized_program (bytecode.c:823)
==1219== Address 0x1C6BE4DA is 10 bytes inside a block of size 12 free'd
==1219== at 0x1B9057CD: free (in /usr/lib/valgrind/vgpreload_memcheck.so)
==1219== by 0x1BF511C6: setlocale (in /lib/tls/libc.so.6)
==1219== by 0x81A5C6F: Fset_current_locale (intl.c:79)
==1219== by 0x80EAB86: Ffuncall (eval.c:3847)
==1219== by 0x809F6CB: execute_optimized_program (bytecode.c:823)
==1219== by 0x80F2418: funcall_compiled_function (eval.c:3457)
==1219== by 0x80EAE62: Ffuncall (eval.c:3886)
==1219== by 0x80E7849: Fcall_with_condition_handler (eval.c:2101)
==1219== by 0x81A5D3B: init_intl (intl.c:174)
==1219== by 0x80DF74A: xemacs_21_5_b22_i686_pc_linux (emacs.c:2500)
==1219== by 0x80E02F1: main (emacs.c:3064)
==1219==
==1219== 3 errors in context 7 of 10:
==1219== Invalid read of size 1
==1219== at 0x1B906656: memcpy (in /usr/lib/valgrind/vgpreload_memcheck.so)
==1219== by 0x81BCE32: fixed_buffer_reader (lstream.c:1468)
==1219== by 0x81BB78C: Lstream_raw_read (lstream.c:628)
==1219== by 0x81BB84A: Lstream_read_more (lstream.c:648)
==1219== by 0x81BBA2E: Lstream_read_1 (lstream.c:714)
==1219== by 0x81BBADA: Lstream_read (lstream.c:743)
==1219== by 0x8250F2B: dfc_convert_to_internal_format (text.c:4435)
==1219== by 0x808E431: make_ext_string (alloc.c:2948)
==1219== by 0x808E4F6: build_ext_string (alloc.c:2972)
==1219== by 0x81A5CD1: Fset_current_locale (intl.c:92)
==1219== by 0x80EAB86: Ffuncall (eval.c:3847)
==1219== by 0x809F6CB: execute_optimized_program (bytecode.c:823)
==1219== Address 0x1C6BE4D2 is 2 bytes inside a block of size 12 free'd
==1219== at 0x1B9057CD: free (in /usr/lib/valgrind/vgpreload_memcheck.so)
==1219== by 0x1BF511C6: setlocale (in /lib/tls/libc.so.6)
==1219== by 0x81A5C6F: Fset_current_locale (intl.c:79)
==1219== by 0x80EAB86: Ffuncall (eval.c:3847)
==1219== by 0x809F6CB: execute_optimized_program (bytecode.c:823)
==1219== by 0x80F2418: funcall_compiled_function (eval.c:3457)
==1219== by 0x80EAE62: Ffuncall (eval.c:3886)
==1219== by 0x80E7849: Fcall_with_condition_handler (eval.c:2101)
==1219== by 0x81A5D3B: init_intl (intl.c:174)
==1219== by 0x80DF74A: xemacs_21_5_b22_i686_pc_linux (emacs.c:2500)
==1219== by 0x80E02F1: main (emacs.c:3064)
==1219==
==1219== 9 errors in context 8 of 10:
==1219== Source and destination overlap in memcpy(0x1C7D4D84, 0x1C7D4D84, 4)
==1219== at 0x1B90671C: memcpy (in /usr/lib/valgrind/vgpreload_memcheck.so)
==1219== by 0x1BC7C37A: (within /usr/X11R6/lib/libXt.so.6.0)
==1219== by 0x1BC7D150: _XtGetSubresources (in /usr/X11R6/lib/libXt.so.6.0)
==1219== by 0x1BC7D2B9: XtGetSubresources (in /usr/X11R6/lib/libXt.so.6.0)
==1219== by 0x1BA7717F: (within /usr/X11R6/lib/libXm.so.3.0.2)
==1219== by 0x1BA76C77: (within /usr/X11R6/lib/libXm.so.3.0.2)
==1219== by 0x1BA67C6D: (within /usr/X11R6/lib/libXm.so.3.0.2)
==1219== by 0x1BC64B77: (within /usr/X11R6/lib/libXt.so.6.0)
==1219== by 0x1BC64B41: (within /usr/X11R6/lib/libXt.so.6.0)
==1219== by 0x1BC64B41: (within /usr/X11R6/lib/libXt.so.6.0)
==1219== by 0x1BC64B41: (within /usr/X11R6/lib/libXt.so.6.0)
==1219== by 0x1BC64B41: (within /usr/X11R6/lib/libXt.so.6.0)
==1219==
==1219== 11 errors in context 9 of 10:
==1219== Invalid read of size 1
==1219== at 0x1B906331: strlen (in /usr/lib/valgrind/vgpreload_memcheck.so)
==1219== by 0x810CBEB: dfc_external_data_len (text.h:287)
==1219== by 0x808E4DC: build_ext_string (alloc.c:2972)
==1219== by 0x81A5CD1: Fset_current_locale (intl.c:92)
==1219== by 0x80EAB86: Ffuncall (eval.c:3847)
==1219== by 0x809F6CB: execute_optimized_program (bytecode.c:823)
==1219== by 0x80F2418: funcall_compiled_function (eval.c:3457)
==1219== by 0x80EAE62: Ffuncall (eval.c:3886)
==1219== by 0x80E7849: Fcall_with_condition_handler (eval.c:2101)
==1219== by 0x81A5D3B: init_intl (intl.c:174)
==1219== by 0x80DF74A: xemacs_21_5_b22_i686_pc_linux (emacs.c:2500)
==1219== by 0x80E02F1: main (emacs.c:3064)
==1219== Address 0x1C6BE4D1 is 1 bytes inside a block of size 12 free'd
==1219== at 0x1B9057CD: free (in /usr/lib/valgrind/vgpreload_memcheck.so)
==1219== by 0x1BF511C6: setlocale (in /lib/tls/libc.so.6)
==1219== by 0x81A5C6F: Fset_current_locale (intl.c:79)
==1219== by 0x80EAB86: Ffuncall (eval.c:3847)
==1219== by 0x809F6CB: execute_optimized_program (bytecode.c:823)
==1219== by 0x80F2418: funcall_compiled_function (eval.c:3457)
==1219== by 0x80EAE62: Ffuncall (eval.c:3886)
==1219== by 0x80E7849: Fcall_with_condition_handler (eval.c:2101)
==1219== by 0x81A5D3B: init_intl (intl.c:174)
==1219== by 0x80DF74A: xemacs_21_5_b22_i686_pc_linux (emacs.c:2500)
==1219== by 0x80E02F1: main (emacs.c:3064)
==1219==
==1219== 18 errors in context 10 of 10:
==1219== Source and destination overlap in memcpy(0x1C8E9040, 0x1C8E9040, 4)
==1219== at 0x1B90671C: memcpy (in /usr/lib/valgrind/vgpreload_memcheck.so)
==1219== by 0x1BC7C37A: (within /usr/X11R6/lib/libXt.so.6.0)
==1219== by 0x1BC7D40F: _XtGetResources (in /usr/X11R6/lib/libXt.so.6.0)
==1219== by 0x1BC6561A: (within /usr/X11R6/lib/libXt.so.6.0)
==1219== by 0x1BC65A79: _XtAppCreateShell (in /usr/X11R6/lib/libXt.so.6.0)
==1219== by 0x1BC65C4F: XtAppCreateShell (in /usr/X11R6/lib/libXt.so.6.0)
==1219== by 0x82649BB: x_init_device (device-x.c:802)
==1219== by 0x80C7A74: Fmake_device (device.c:660)
==1219== by 0x80EABCE: Ffuncall (eval.c:3847)
==1219== by 0x809F6CB: execute_optimized_program (bytecode.c:823)
==1219== by 0x80F2418: funcall_compiled_function (eval.c:3457)
==1219== by 0x80EAE62: Ffuncall (eval.c:3886)
--
Marcus
5:14 p.m.
New subject: [AC21.5] segfault during compilation
>>>> "Marcus" == Marcus Crestani
<crestani(a)informatik.uni-tuebingen.de> writes:
Marcus> $ valgrind -v ./xemacs -vanilla -kill
Thanks! The setlocale one is probably the one Olivier just found, and
the one deep in Xt probably is in fact in Xt. But the others look
like XEmacs bugs to me.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7:08 p.m.
New subject: [AC21.5] segfault during compilation
>>>>"SJT" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
SJT> Thanks! The setlocale one is probably
the one Olivier just
SJT> found, and the one deep in Xt probably is in fact in Xt. But the
SJT> others look like XEmacs bugs to me.
After I applied Olivier's patch, all XEmacs bugs valgrind has found
before are gone:
==1168== ERROR SUMMARY: 29 errors from 3 contexts (suppressed: 92 from 2)
==1168==
==1168== 2 errors in context 1 of 3:
==1168== Conditional jump or move depends on uninitialised value(s)
==1168== at 0x82AA372: xm_update_label (lwlib-Xm.c:222)
==1168== by 0x82AA647: xm_safe_update_label (lwlib-Xm.c:314)
==1168== by 0x82AAC9B: xm_update_one_widget (lwlib-Xm.c:854)
==1168== by 0x82B3FE3: xlw_update_tab_control (lwlib-Xlw.c:458)
==1168== by 0x82B4243: xlw_update_one_widget (lwlib-Xlw.c:578)
==1168== by 0x82A8906: set_one_value (lwlib.c:718)
==1168== by 0x82A897B: update_one_widget_instance (lwlib.c:742)
==1168== by 0x82A8BEC: initialize_widget_instance (lwlib.c:821)
==1168== by 0x82A8FE0: lw_make_widget (lwlib.c:974)
==1168== by 0x82A9051: lw_create_widget (lwlib.c:989)
==1168== by 0x827D09A: x_widget_instantiate (glyphs-x.c:2468)
==1168== by 0x827D874: x_tab_control_instantiate (glyphs-x.c:2678)
==1168==
==1168== 9 errors in context 2 of 3:
==1168== Source and destination overlap in memcpy(0x1C48B994, 0x1C48B994, 4)
==1168== at 0x1B90671C: memcpy (in /usr/lib/valgrind/vgpreload_memcheck.so)
==1168== by 0x1BC7C37A: (within /usr/X11R6/lib/libXt.so.6.0)
==1168== by 0x1BC7D150: _XtGetSubresources (in /usr/X11R6/lib/libXt.so.6.0)
==1168== by 0x1BC7D2B9: XtGetSubresources (in /usr/X11R6/lib/libXt.so.6.0)
==1168== by 0x1BA7717F: (within /usr/X11R6/lib/libXm.so.3.0.2)
==1168== by 0x1BA76C77: (within /usr/X11R6/lib/libXm.so.3.0.2)
==1168== by 0x1BA67C6D: (within /usr/X11R6/lib/libXm.so.3.0.2)
==1168== by 0x1BC64B77: (within /usr/X11R6/lib/libXt.so.6.0)
==1168== by 0x1BC64B41: (within /usr/X11R6/lib/libXt.so.6.0)
==1168== by 0x1BC64B41: (within /usr/X11R6/lib/libXt.so.6.0)
==1168== by 0x1BC64B41: (within /usr/X11R6/lib/libXt.so.6.0)
==1168== by 0x1BC64B41: (within /usr/X11R6/lib/libXt.so.6.0)
==1168==
==1168== 18 errors in context 3 of 3:
==1168== Source and destination overlap in memcpy(0x1C484680, 0x1C484680, 4)
==1168== at 0x1B90671C: memcpy (in /usr/lib/valgrind/vgpreload_memcheck.so)
==1168== by 0x1BC7C37A: (within /usr/X11R6/lib/libXt.so.6.0)
==1168== by 0x1BC7D40F: _XtGetResources (in /usr/X11R6/lib/libXt.so.6.0)
==1168== by 0x1BC6561A: (within /usr/X11R6/lib/libXt.so.6.0)
==1168== by 0x1BC65A79: _XtAppCreateShell (in /usr/X11R6/lib/libXt.so.6.0)
==1168== by 0x1BC65C4F: XtAppCreateShell (in /usr/X11R6/lib/libXt.so.6.0)
==1168== by 0x82649F7: x_init_device (device-x.c:802)
==1168== by 0x80C7A74: Fmake_device (device.c:660)
==1168== by 0x80EABCE: Ffuncall (eval.c:3847)
==1168== by 0x809F6CB: execute_optimized_program (bytecode.c:823)
==1168== by 0x80F2418: funcall_compiled_function (eval.c:3457)
==1168== by 0x80EAE62: Ffuncall (eval.c:3886)
--
Marcus
4:37 p.m.
New subject: [AC21.5] segfault during compilation
Alexey Mahotkin <squadette(a)gmail.com> wrote:
(gdb) print l2
$1 = (struct level_2_lookup_tree *) 0x3
I think it should tell you something :)
What are the exact compiler flags, and what version of gcc is being
used? What are the contents of, "Installation"? Also, is this 32- or
64-bit linux (and which one, for that matter)?
--
Darryl Okahata
darrylo(a)soco.agilent.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.
4:55 p.m.
New subject: [AC21.5] segfault during compilation
On 9/15/05, Darryl Okahata <darrylo(a)soco.agilent.com> wrote:
What are the exact compiler flags, and what version of gcc is
being
used? What are the contents of, "Installation"? Also, is this 32- or
64-bit linux (and which one, for that matter)?
Here is Installation:
uname -a: Linux derby 2.6.11.11 #5 SMP Sat Jun 11 15:16:23 MSD 2005
i686 athlon i386 GNU/Linux
./configure '--prefix=/usr/local/xemacs-21.5' '--enable-mule'
XEmacs 21.5-b21 "corn" (+CVS-20050527) configured for `i686-pc-linux'.
WARNING: --------------------------------------------------------------
WARNING: This was produced from a new autoconf-2.5 based configuration.
WARNING: If this configuration seems buggy then copy etc/configure-2.13
WARNING: to configure and try again. Also please report the bug.
WARNING: --------------------------------------------------------------
Compilation Environment and Installation Defaults:
Source code location: /home/alexm/src/xemacs-21.5.21
Installation prefix: /usr/local/xemacs-21.5
Operating system description file: `s/linux.h'
Machine description file: `m/intel386.h'
Compiler version: gcc (GCC) 3.2 20020903 (Red Hat
Linux 8.0 3.2-7)
- GCC specs file:
/usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
- Compiler command: gcc -Wall -Wno-switch -Wundef
-Wsign-compare -Wno-char-subscripts -Wpacked -Wunused-parameter -g
libc version: glibc-2.2.93-5
Relocating allocator for buffers: no
GNU version of malloc: yes
- Using Doug Lea's new malloc from the GNU C Library.
Window System:
Compiling in support for the X window system:
- X Windows headers location: /usr/X11R6/include
- X Windows libraries location: /usr/X11R6/lib
- Handling WM_COMMAND properly.
Using Lucid menubars.
Using Lucid scrollbars.
Using Motif dialog boxes.
Using Motif native widgets.
TTY:
Compiling in support for ncurses.
Compiling in support for GPM (General Purpose Mouse).
Images:
Compiling in support for GIF images (builtin).
Compiling in support for XPM images.
Compiling in support for PNG images.
Compiling in support for JPEG images.
Compiling in support for TIFF images.
Sound:
Compiling in support for sound (native).
Databases:
Compiling in support for Berkeley database.
Compiling in support for LDAP.
Compiling in support for PostgreSQL.
- Using PostgreSQL header file: libpq-fe.h
- Using PostgreSQL V7 bindings.
Internationalization:
Compiling in support for Mule (multi-lingual Emacs).
Compiling in support for XIM (X11R5+ I18N input method).
- Using Motif to provide XIM support.
Mail:
Compiling in support for "file" mail spool file locking method.
Other Features:
Inhibiting IPv6 canonicalization at startup.
Compiling in support for dynamic shared object modules.
Using the new GC algorithms.
WARNING: ---------------------------------------------------------
WARNING: The new algorithms are experimental. They are enabled by
WARNING: default for this release. Use `--disable-kkcc' to
WARNING: turn it off.
WARNING: ---------------------------------------------------------
Using the new allocator.
WARNING: ---------------------------------------------------------
WARNING: The new allocator is experimental. It is enabled by
WARNING: default for this release. Use `--disable-mc-alloc' to
WARNING: turn it off.
WARNING: ---------------------------------------------------------
Using the new portable dumper.
Compiling in support for extra debugging code.
Compiling in support for runtime error checking.
WARNING: ---------------------------------------------------------
WARNING: XEmacs will run noticeably more slowly as a result.
WARNING: Error checking is on by default for XEmacs beta releases.
WARNING: ---------------------------------------------------------
--alexm
5:01 p.m.
New subject: [AC21.5] segfault during compilation
On 9/15/05, Alexey Mahotkin <squadette(a)gmail.com> wrote:
Here is Installation:
WARNING: --------------------------------------------------------------
WARNING: This was produced from a new autoconf-2.5 based configuration.
WARNING: If this configuration seems buggy then copy etc/configure-2.13
WARNING: to configure and try again. Also please report the bug.
WARNING: --------------------------------------------------------------
I tried to do as it says, but it does not recognize "--mc-alloc"
option that help mentions.
alexm＠derby:~/src/xemacs-21.5.21$ ./configure
--prefix=/usr/local/xemacs-21.5 --with-mule --mc-alloc
./configure: Usage error:
Unrecognized option: --mc-alloc
Use `./configure --help' to show usage.
alexm＠derby:~/src/xemacs-21.5.21$ ./configure --help | grep mc
--with-wmcommand=no Compile without realized leader window which will
combination with `mc-alloc'.
--mc-alloc Enable the new allocator. (EXPERIMENTAL)
When I edit src/config.h and turn on MC_ALLOC, it says:
abbrev.o: In function `syms_of_abbrev':
/home/alexm/src/xemacs-21.5.21/src/abbrev.c:410: undefined reference
to `mc_alloc'
and so on.
--alexm
5:57 p.m.
New subject: [AC21.5] segfault during compilation
Alexey Mahotkin <squadette(a)gmail.com> wrote:
> WARNING:
--------------------------------------------------------------
> WARNING: This was produced from a new autoconf-2.5 based configuration.
> WARNING: If this configuration seems buggy then copy etc/configure-2.13
> WARNING: to configure and try again. Also please report the bug.
> WARNING: --------------------------------------------------------------
I tried to do as it says, but it does not recognize "--mc-alloc"
option that help mentions.
Go back to using the original "configure" script, and use (but add
"--with-mule" and any other options you normally use):
configure --disable-kkcc --disable-mc-alloc
(BTW, going back to the old garbage collector makes XEmacs run MUCH
faster.)
If you're feeling lucky, you can also disable the optional error
checking and debugging code with these configure options:
--disable-error-checking --disable-assertions --disable-debug
--
Darryl Okahata
darrylo(a)soco.agilent.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.
6:06 p.m.
New subject: [AC21.5] segfault during compilation
On 9/15/05, Darryl Okahata <darrylo(a)soco.agilent.com> wrote:
Go back to using the original "configure" script, and
use (but add
"--with-mule" and any other options you normally use):
configure --disable-kkcc --disable-mc-alloc
Of course this bug goes away when I disable mc-alloc.
(BTW, going back to the old garbage collector makes XEmacs run MUCH
faster.)
If you're feeling lucky, you can also disable the optional error
checking and debugging code with these configure options:
--disable-error-checking --disable-assertions --disable-debug
If you're trying to help me to make xemacs up and running -- do not
worry: the whole point of this exercise is to debug mc-alloc on
(unusual? broken?) configuration. Seems like we already caught(?)
an unrelated bug with this.
I could always disable all new features and make it work (I hope so :)
Thanks,
--alexm
9:33 a.m.
New subject: [AC21.5] segfault during compilation
>>>>"AM" == Alexey Mahotkin
<squadette(a)gmail.com> writes:
AM> WARNING:
--------------------------------------------------------------
AM> WARNING: This was produced from a new autoconf-2.5 based configuration.
AM> WARNING: If this configuration seems buggy then copy etc/configure-2.13
AM> WARNING: to configure and try again. Also please report the bug.
AM> WARNING: --------------------------------------------------------------
AM> I tried to do as it says, but it does not recognize "--mc-alloc"
AM> option that help mentions.
AM> alexm＠derby:~/src/xemacs-21.5.21$ ./configure --help | grep mc
AM> --with-wmcommand=no Compile without realized leader window which will
AM> combination with `mc-alloc'.
AM> --mc-alloc Enable the new allocator. (EXPERIMENTAL)
The script etc/configure-2.13 differs largely form a freshly generated
configure script by autoconf-2.13. etc/configure-2.13 obviously has
not been updated whenever configure.in has been.
After copying etc/configure-2.13 to configure, `./configure --help'
shows configure.usage of the root directory that reflects the
up-to-date configure.in. Thus, the version of the help information
differs from the version of the script, and we run in to the above
problem.
Is it worth to update etc/autoconf-2.13, or do we remove the old
configure.in soon?
--
Marcus
9:58 a.m.
New subject: [AC21.5] segfault during compilation
>>>> "Marcus" == Marcus Crestani
<crestani(a)informatik.uni-tuebingen.de> writes:
Marcus> Is it worth to update etc/autoconf-2.13, or do we remove
Marcus> the old configure.in soon?
configure.in is going away very soon.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7004
days inactive
7010
days old
29 comments
5 participants
participants (5)
-
Alexey Mahotkin -
Darryl Okahata -
Hrvoje Niksic -
Marcus Crestani -
Stephen J. Turnbull