crash on __gmpz_init

Vincent Lefevre vincent at
Mon Jan 22 14:56:03 CET 2024

On 2024-01-22 11:51:21 +0100, Vincent Lefevre wrote:
> On 2024-01-22 11:02:21 +0100, Marc Glisse wrote:
> > Hello,
> > 
> >   mpz_class M[LINES][COLS];
> > 
> > you are trying to put an array with millions of elements on the stack, so
> > the stack overflows. Very large arrays need to be allocated on the heap in
> > C++ (new, malloc, or some wrapper like std::vector).
> Note that the user has a segmentation fault in __gmpz_init for
> test2_mem.c too (tc_7000x5000), which uses malloc(). See the
> gdb output.

I can reproduce the issue, even with a much smaller array:

qaa:~> gcc -DLINES=70 -DCOLS=10 -DSC=1 test2_mem.c -lgmp -o test2_mem
qaa:~> ./test2_mem
allocating 700; size=16
malloc(): corrupted top size
zsh: IOT instruction (core dumped)  ./test2_mem

And with valgrind:

==649064== Memcheck, a memory error detector
==649064== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==649064== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==649064== Command: ./test2_mem
allocating 700; size=16
==649064== Invalid write of size 8
==649064==    at 0x488B147: __gmpz_init (in /usr/lib/x86_64-linux-gnu/
==649064==    by 0x109271: main (in /home/vinc17/test2_mem)
==649064==  Address 0x4ad8040 is 0 bytes after a block of size 11,200 alloc'd
==649064==    at 0x48407B4: malloc (vg_replace_malloc.c:381)
==649064==    by 0x109218: main (in /home/vinc17/test2_mem)
==649064== Invalid write of size 8
==649064==    at 0x488B14E: __gmpz_init (in /usr/lib/x86_64-linux-gnu/
==649064==    by 0x109271: main (in /home/vinc17/test2_mem)
==649064==  Address 0x4ad8048 is 8 bytes after a block of size 11,200 alloc'd
==649064==    at 0x48407B4: malloc (vg_replace_malloc.c:381)
==649064==    by 0x109218: main (in /home/vinc17/test2_mem)

valgrind: m_mallocfree.c:278 (mk_plain_bszB): Assertion 'bszB != 0' failed.
valgrind: This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata.  If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away.  Please try that before reporting this as a bug.

host stacktrace:
==649064==    at 0x580429AA: show_sched_status_wrk (m_libcassert.c:406)
==649064==    by 0x58042AC7: report_and_quit (m_libcassert.c:477)
==649064==    by 0x58042C57: vgPlain_assert_fail (m_libcassert.c:543)
==649064==    by 0x5804CA6C: mk_plain_bszB (m_mallocfree.c:278)
==649064==    by 0x5804CA6C: mk_plain_bszB (m_mallocfree.c:276)
==649064==    by 0x5804CA6C: get_bszB_as_is (m_mallocfree.c:301)
==649064==    by 0x5804CA6C: get_bszB (m_mallocfree.c:313)
==649064==    by 0x5804CA6C: get_next_b (m_mallocfree.c:432)
==649064==    by 0x5804CA6C: vgPlain_arena_malloc (m_mallocfree.c:1806)
==649064==    by 0x58004FE4: vgMemCheck_new_block (mc_malloc_wrappers.c:370)
==649064==    by 0x580051CA: vgMemCheck_malloc (mc_malloc_wrappers.c:405)
==649064==    by 0x5809A08B: do_client_request (scheduler.c:1956)
==649064==    by 0x5809A08B: vgPlain_scheduler (scheduler.c:1519)
==649064==    by 0x580E1B6C: thread_wrapper (syswrap-linux.c:101)
==649064==    by 0x580E1B6C: run_a_thread_NORETURN (syswrap-linux.c:154)

sched status:

Thread 1: status = VgTs_Runnable (lwpid 649064)
==649064==    at 0x48407B4: malloc (vg_replace_malloc.c:381)
==649064==    by 0x487A968: __gmp_default_allocate (in /usr/lib/x86_64-linux-gnu/
==649064==    by 0x4891FD3: __gmpz_realloc (in /usr/lib/x86_64-linux-gnu/
==649064==    by 0x489305E: __gmpz_set_si (in /usr/lib/x86_64-linux-gnu/
==649064==    by 0x1092CB: main (in /home/vinc17/test2_mem)
client stack range: [0x1FFEFFD000 0x1FFF000FFF] client SP: 0x1FFEFFF540
valgrind stack range: [0x1002CAA000 0x1002DA9FFF] top usage: 18792 of 1048576

Vincent Lefèvre <vincent at> - Web: <>
100% accessible validated (X)HTML - Blog: <>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

More information about the gmp-bugs mailing list