OK, I compiled revision 3003, still signal 11.
But different valgrind output (see attachment).
Jussi
2010/6/13 Benoît Minisini <gam...@users.sourceforge.net>:
>> > What happens if you declare Aja_Mtrx that way?
>> >
>> > void Aja_Mtrx(int k0[31][], int k1[31][], int k2[31][])
>>
>> It trows error: "array type has incomplete element type"
>>
>> > And that way?
>> >
>> > void Aja_Mtrx(int k0[31][31], int k1[31][31], int k2[31][31])
>>
>> Same, signal 11.
>>
>>
>
> Do you have the same valgrind memcheck output? Can you use the last subversion
> revision?
>
> --
> Benoît Minisini
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Gambas-user mailing list
> Gambas-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
>
==32067== Memcheck, a memory error detector
==32067== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==32067== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==32067== Command: gbx3 -p
==32067== Parent PID: 32049
==32067==
==32067== Use of uninitialised value of size 8
==32067== at 0xF1A6613: Aja_Mtrx (main.c:12)
==32067== by 0x54D7EFB: ffi_call_unix64 (in /usr/lib/libffi.so.5.0.10)
==32067== by 0x54D7C83: ffi_call (in /usr/lib/libffi.so.5.0.10)
==32067== by 0x42B764: EXTERN_call (gbx_extern.c:346)
==32067== by 0x42F26B: EXEC_loop (gbx_exec_loop.c:1076)
==32067== by 0x40A4E6: EXEC_function_loop (gbx_exec.c:783)
==32067== by 0x40B073: EXEC_function_real (gbx_exec.c:770)
==32067== by 0x41C4F9: raise_event (gbx_api.c:480)
==32067== by 0x41CCD4: GB_Raise (gbx_api.c:580)
==32067== by 0x62FEFDE: gb_raise_window_Open(gMainWindow*) (CWindow.cpp:75)
==32067== by 0x62BD44F: gControl::emit(void*) (gcontrol.cpp:1473)
==32067== by 0x62DE77E: gMainWindow::emitOpen() (gmainwindow.cpp:415)
==32067== by 0x62DE849: gMainWindow::setVisible(bool) (gmainwindow.cpp:440)
==32067== by 0x62ECA4F: gControl::show() (gcontrol.h:135)
==32067== by 0x62FF9B5: CWINDOW_show(void*, void*) (CWindow.cpp:375)
==32067== by 0x6300651: CFORM_main(void*, void*) (CWindow.cpp:686)
==32067== by 0x40A0A1: EXEC_native (gbx_exec.c:1188)
==32067== by 0x40BB3D: EXEC_public_desc (gbx_exec.c:1440)
==32067== by 0x421FC3: main (gbx.c:358)
==32067==
==32067== Invalid write of size 4
==32067== at 0xF1A6613: Aja_Mtrx (main.c:12)
==32067== by 0x54D7EFB: ffi_call_unix64 (in /usr/lib/libffi.so.5.0.10)
==32067== by 0x54D7C83: ffi_call (in /usr/lib/libffi.so.5.0.10)
==32067== by 0x42B764: EXTERN_call (gbx_extern.c:346)
==32067== by 0x42F26B: EXEC_loop (gbx_exec_loop.c:1076)
==32067== by 0x40A4E6: EXEC_function_loop (gbx_exec.c:783)
==32067== by 0x40B073: EXEC_function_real (gbx_exec.c:770)
==32067== by 0x41C4F9: raise_event (gbx_api.c:480)
==32067== by 0x41CCD4: GB_Raise (gbx_api.c:580)
==32067== by 0x62FEFDE: gb_raise_window_Open(gMainWindow*) (CWindow.cpp:75)
==32067== by 0x62BD44F: gControl::emit(void*) (gcontrol.cpp:1473)
==32067== by 0x62DE77E: gMainWindow::emitOpen() (gmainwindow.cpp:415)
==32067== by 0x62DE849: gMainWindow::setVisible(bool) (gmainwindow.cpp:440)
==32067== by 0x62ECA4F: gControl::show() (gcontrol.h:135)
==32067== by 0x62FF9B5: CWINDOW_show(void*, void*) (CWindow.cpp:375)
==32067== by 0x6300651: CFORM_main(void*, void*) (CWindow.cpp:686)
==32067== by 0x40A0A1: EXEC_native (gbx_exec.c:1188)
==32067== by 0x40BB3D: EXEC_public_desc (gbx_exec.c:1440)
==32067== by 0x421FC3: main (gbx.c:358)
==32067== Address 0x457f06f5 is not stack'd, malloc'd or (recently) free'd
==32067==
==32067==
==32067== Process terminating with default action of signal 11 (SIGSEGV)
==32067== Access not within mapped region at address 0x457F06F5
==32067== at 0xF1A6613: Aja_Mtrx (main.c:12)
==32067== by 0x54D7EFB: ffi_call_unix64 (in /usr/lib/libffi.so.5.0.10)
==32067== by 0x54D7C83: ffi_call (in /usr/lib/libffi.so.5.0.10)
==32067== by 0x42B764: EXTERN_call (gbx_extern.c:346)
==32067== by 0x42F26B: EXEC_loop (gbx_exec_loop.c:1076)
==32067== by 0x40A4E6: EXEC_function_loop (gbx_exec.c:783)
==32067== by 0x40B073: EXEC_function_real (gbx_exec.c:770)
==32067== by 0x41C4F9: raise_event (gbx_api.c:480)
==32067== by 0x41CCD4: GB_Raise (gbx_api.c:580)
==32067== by 0x62FEFDE: gb_raise_window_Open(gMainWindow*) (CWindow.cpp:75)
==32067== by 0x62BD44F: gControl::emit(void*) (gcontrol.cpp:1473)
==32067== by 0x62DE77E: gMainWindow::emitOpen() (gmainwindow.cpp:415)
==32067== by 0x62DE849: gMainWindow::setVisible(bool) (gmainwindow.cpp:440)
==32067== by 0x62ECA4F: gControl::show() (gcontrol.h:135)
==32067== by 0x62FF9B5: CWINDOW_show(void*, void*) (CWindow.cpp:375)
==32067== by 0x6300651: CFORM_main(void*, void*) (CWindow.cpp:686)
==32067== by 0x40A0A1: EXEC_native (gbx_exec.c:1188)
==32067== by 0x40BB3D: EXEC_public_desc (gbx_exec.c:1440)
==32067== by 0x421FC3: main (gbx.c:358)
==32067== If you believe this happened as a result of a stack
==32067== overflow in your program's main thread (unlikely but
==32067== possible), you can try to increase the size of the
==32067== main thread stack using the --main-stacksize= flag.
==32067== The main thread stack size used in this run was 8388608.
==32067==
==32067== HEAP SUMMARY:
==32067== in use at exit: 1,181,987 bytes in 5,972 blocks
==32067== total heap usage: 12,577 allocs, 6,605 frees, 1,661,010 bytes allocated
==32067==
==32067== LEAK SUMMARY:
==32067== definitely lost: 11,540 bytes in 250 blocks
==32067== indirectly lost: 464 bytes in 13 blocks
==32067== possibly lost: 758,842 bytes in 2,493 blocks
==32067== still reachable: 395,629 bytes in 3,064 blocks
==32067== suppressed: 15,512 bytes in 152 blocks
==32067== Rerun with --leak-check=full to see details of leaked memory
==32067==
==32067== For counts of detected and suppressed errors, rerun with: -v
==32067== Use --track-origins=yes to see where uninitialised values come from
==32067== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user
