[Gambas-user] Segfault with certain array sizes

Tobias Boege taboege at ...626...
Fri Aug 21 10:04:50 CEST 2015


Hi Benoit (or Adrien, as I've seen you are a good substitute :-)),

while testing a project for a thread by martin p cristia yesterday, I saw
that segfaults could occur when allocating an array of certain size. Use the
attached project to create a Float[] of different numbers of elements. Over
here, I have these numbers which yield consistent results:

  - 200: OK,
  - 210: Segfault,
  - 300: Out of memory.

gdb and valgrind logs are attached.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alloc-test-0.0.1.tar.gz
Type: application/octet-stream
Size: 3841 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20150821/e5ab8006/attachment.obj>
-------------- next part --------------
(gdb) r -- 210
Program received signal SIGSEGV, Segmentation fault.
0x00000000004064e9 in my_malloc (len=18446744071616593936) at ../share/gb_alloc_temp.h:351
351     ../share/gb_alloc_temp.h: No such file or directory.
(gdb) bt
#0  0x00000000004064e9 in my_malloc (len=18446744071616593936) at ../share/gb_alloc_temp.h:351
#1  0x0000000000406724 in my_realloc (alloc=0x69c0d8, new_len=18446744071616593936) at ../share/gb_alloc_temp.h:477
#2  0x00000000004068e5 in ARRAY_add_data (p_data=0x69c0a8, num=220200960, zero=1 '\001') at ../share/gb_array_temp.h:74
#3  0x000000000044fa28 in Array_new (_object=0x69c088, _param=0x7ffff65d8080) at gbx_c_array.c:482
#4  0x000000000041273d in EXEC_native () at gbx_exec.c:1366
#5  0x00000000004136ed in EXEC_special (special=0, class=0x695198, object=0x69c088, nparam=1, drop=1 '\001') at gbx_exec.c:1674
#6  0x0000000000413d37 in EXEC_special_inheritance (special=0, class=0x695198, object=0x69c088, nparam=0, drop=1 '\001') at gbx_exec.c:1829
#7  0x00000000004145c9 in EXEC_new () at gbx_exec.c:1947
#8  0x000000000045e76b in EXEC_loop () at gbx_exec_loop.c:907
#9  0x00000000004109dd in EXEC_function_loop () at gbx_exec.c:931
#10 0x000000000041062a in EXEC_function_real () at gbx_exec.c:895
#11 0x0000000000413562 in EXEC_public_desc (class=0x69aed8, object=0x0, desc=0x69bad8, nparam=0) at gbx_exec.c:1616
#12 0x000000000044412c in main (argc=2, argv=0x7fffffffe698) at gbx.c:416
-------------- next part --------------
==21233== Memcheck, a memory error detector
==21233== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==21233== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==21233== Command: gbx3 -- 210
==21233== Parent PID: 19928
==21233== 
==21233== Invalid read of size 4
==21233==    at 0x4064E9: my_malloc (gb_alloc_temp.h:351)
==21233==    by 0x406723: my_realloc (gb_alloc_temp.h:477)
==21233==    by 0x4068E4: ARRAY_add_data (gb_array_temp.h:74)
==21233==    by 0x44FA27: Array_new (gbx_c_array.c:482)
==21233==    by 0x41273C: EXEC_native (gbx_exec.c:1366)
==21233==    by 0x4136EC: EXEC_special (gbx_exec.c:1674)
==21233==    by 0x413D36: EXEC_special_inheritance (gbx_exec.c:1829)
==21233==    by 0x4145C8: EXEC_new (gbx_exec.c:1947)
==21233==    by 0x45E76A: EXEC_loop (gbx_exec_loop.c:907)
==21233==    by 0x4109DC: EXEC_function_loop (gbx_exec.c:931)
==21233==    by 0x410629: EXEC_function_real (gbx_exec.c:895)
==21233==    by 0x413561: EXEC_public_desc (gbx_exec.c:1616)
==21233==  Address 0xffffffffe13898a4 is not stack'd, malloc'd or (recently) free'd
==21233== 
==21233== 
==21233== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==21233==  Access not within mapped region at address 0xFFFFFFFFE13898A4
==21233==    at 0x4064E9: my_malloc (gb_alloc_temp.h:351)
==21233==    by 0x406723: my_realloc (gb_alloc_temp.h:477)
==21233==    by 0x4068E4: ARRAY_add_data (gb_array_temp.h:74)
==21233==    by 0x44FA27: Array_new (gbx_c_array.c:482)
==21233==    by 0x41273C: EXEC_native (gbx_exec.c:1366)
==21233==    by 0x4136EC: EXEC_special (gbx_exec.c:1674)
==21233==    by 0x413D36: EXEC_special_inheritance (gbx_exec.c:1829)
==21233==    by 0x4145C8: EXEC_new (gbx_exec.c:1947)
==21233==    by 0x45E76A: EXEC_loop (gbx_exec_loop.c:907)
==21233==    by 0x4109DC: EXEC_function_loop (gbx_exec.c:931)
==21233==    by 0x410629: EXEC_function_real (gbx_exec.c:895)
==21233==    by 0x413561: EXEC_public_desc (gbx_exec.c:1616)
==21233==  If you believe this happened as a result of a stack
==21233==  overflow in your program's main thread (unlikely but
==21233==  possible), you can try to increase the size of the
==21233==  main thread stack using the --main-stacksize= flag.
==21233==  The main thread stack size used in this run was 8388608.
==21233== 
==21233== HEAP SUMMARY:
==21233==     in use at exit: 41,376 bytes in 244 blocks
==21233==   total heap usage: 347 allocs, 103 frees, 57,270 bytes allocated
==21233== 
==21233== LEAK SUMMARY:
==21233==    definitely lost: 80 bytes in 2 blocks
==21233==    indirectly lost: 0 bytes in 0 blocks
==21233==      possibly lost: 41,264 bytes in 241 blocks
==21233==    still reachable: 32 bytes in 1 blocks
==21233==         suppressed: 0 bytes in 0 blocks
==21233== Rerun with --leak-check=full to see details of leaked memory
==21233== 
==21233== For counts of detected and suppressed errors, rerun with: -v
==21233== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)


More information about the User mailing list