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
alloc-test-0.0.1.tar.gz
Description: Binary data
(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
==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)
------------------------------------------------------------------------------
_______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user