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
==649064== 
allocating 700; size=16
==649064== Invalid write of size 8
==649064==    at 0x488B147: __gmpz_init (in 
/usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0)
==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== 
==649064== Invalid write of size 8
==649064==    at 0x488B14E: __gmpz_init (in 
/usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0)
==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)
==649064== 

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:
  running_tid=1

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/libgmp.so.10.5.0)
==649064==    by 0x4891FD3: __gmpz_realloc (in 
/usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0)
==649064==    by 0x489305E: __gmpz_set_si (in 
/usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0)
==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 <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
_______________________________________________
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Reply via email to