[Gambas-user] gb.gsl Polynomial segfault

[Benoît Minisini]

Le 02/01/2014 21:01, Tobias Boege a écrit :
> Hi,
>
> I get a segfault from gb.gsl when running the attached project. I looked at
> the source and it seems I am allowed to do this... Even if I'm not, a
> segfault isn't the most charming way to tell me ;-)
>
> GDB output:
>
> (gdb) r
> Starting program: /usr/bin/gbx3
> warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
> warning: Could not load shared library symbols for linux-vdso.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/usr/lib/libthread_db.so.1".
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000406aff in ARRAY_insert_many (p_data=0x695c20, pos=-1, count=1) at ../share/gb_array_temp.h:166
> 166         pos = array->count;
> (gdb) bt
> #0  0x0000000000406aff in ARRAY_insert_many (p_data=0x695c20, pos=-1, count=1) at ../share/gb_array_temp.h:166
> #1  0x00007ffff66ff0fc in ensure_size (_object=0x695c08, size=1) at c_polynomial.c:93
> #2  0x00007ffff6700be6 in Polynomial_put (_object=0x695c08, _param=0x7ffff6907040) at c_polynomial.c:680
> #3  0x000000000041244e in EXEC_native () at gbx_exec.c:1344
> #4  0x00000000004133f5 in EXEC_special (special=3, class=0x693998, object=0x695c08, nparam=2, drop=1 '\001') at gbx_exec.c:1652
> #5  0x0000000000417e86 in EXEC_pop_array (code=2818) at gbx_exec_pop.c:400
> #6  0x000000000045b835 in EXEC_loop () at gbx_exec_loop.c:662
> #7  0x00000000004106ed in EXEC_function_loop () at gbx_exec.c:909
> #8  0x0000000000410344 in EXEC_function_real () at gbx_exec.c:873
> #9  0x000000000041326d in EXEC_public_desc (class=0x695598, object=0x0, desc=0x695758, nparam=0) at gbx_exec.c:1594
> #10 0x00000000004436f5 in main (argc=1, argv=0x7fffffffe968) at gbx.c:391
>
> valgrind output:
>
> ==18869== Invalid read of size 4
> ==18869==    at 0x406AFF: ARRAY_insert_many (gb_array_temp.h:166)
> ==18869==    by 0x67170FB: ensure_size (c_polynomial.c:93)
> ==18869==    by 0x6718BE5: Polynomial_put (c_polynomial.c:680)
> ==18869==    by 0x41244D: EXEC_native (gbx_exec.c:1344)
> ==18869==    by 0x4133F4: EXEC_special (gbx_exec.c:1652)
> ==18869==    by 0x417E85: EXEC_pop_array (gbx_exec_pop.c:400)
> ==18869==    by 0x45B834: EXEC_loop (gbx_exec_loop.c:662)
> ==18869==    by 0x4106EC: EXEC_function_loop (gbx_exec.c:909)
> ==18869==    by 0x410343: EXEC_function_real (gbx_exec.c:873)
> ==18869==    by 0x41326C: EXEC_public_desc (gbx_exec.c:1594)
> ==18869==    by 0x4436F4: main (gbx.c:391)
> ==18869==  Address 0xfffffffffffffff0 is not stack'd, malloc'd or (recently) free'd
> ==18869==
> ==18869==
> ==18869== Process terminating with default action of signal 11 (SIGSEGV): dumping core
> ==18869==  Access not within mapped region at address 0xFFFFFFFFFFFFFFF0
> ==18869==    at 0x406AFF: ARRAY_insert_many (gb_array_temp.h:166)
> ==18869==    by 0x67170FB: ensure_size (c_polynomial.c:93)
> ==18869==    by 0x6718BE5: Polynomial_put (c_polynomial.c:680)
> ==18869==    by 0x41244D: EXEC_native (gbx_exec.c:1344)
> ==18869==    by 0x4133F4: EXEC_special (gbx_exec.c:1652)
> ==18869==    by 0x417E85: EXEC_pop_array (gbx_exec_pop.c:400)
> ==18869==    by 0x45B834: EXEC_loop (gbx_exec_loop.c:662)
> ==18869==    by 0x4106EC: EXEC_function_loop (gbx_exec.c:909)
> ==18869==    by 0x410343: EXEC_function_real (gbx_exec.c:873)
> ==18869==    by 0x41326C: EXEC_public_desc (gbx_exec.c:1594)
> ==18869==    by 0x4436F4: main (gbx.c:391)
> ==18869==  If you believe this happened as a result of a stack
> ==18869==  overflow in your program's main thread (unlikely but
> ==18869==  possible), you can try to increase the size of the
> ==18869==  main thread stack using the --main-stacksize= flag.
> ==18869==  The main thread stack size used in this run was 8388608.
>
> Regards,
> Tobi
>

Fixed in revision #6055.

Regards,

-- 
Benoît Minisini