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