Hi!
I cannot really isolate my problem, but in this case it happens when loading
string data from file to object
(something like "someobject.sStr = Read #hFile As String").

Gambas 3 rev 3447 @ Ubuntu 10.10 64bit

$ gbc3 -agpmt
OK
$ gdb gbx3
GNU gdb (GDB) 7.2-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/bin/gbx3...done.
(gdb) set args -p
(gdb) run
Starting program: /usr/local/bin/gbx3 -p
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffef2ba700 (LWP 3790)]
warning: unable to load Qt translation: en_GB.utf8

Program received signal SIGSEGV, Segmentation fault.
0x0000000000414b91 in SUBR_leave (nparam=2) at gbx_subr.c:42
42      BORROW(RP);
(gdb) bt
#0  0x0000000000414b91 in SUBR_leave (nparam=2) at gbx_subr.c:42
#1  0x0000000000430132 in EXEC_loop () at gbx_exec_loop.c:480
#2  0x0000000000409a75 in EXEC_function_loop () at gbx_exec.c:861
#3  0x000000000040a4c5 in EXEC_function_real () at gbx_exec.c:848
#4  0x00000000004227e5 in main (argc=1, argv=<value optimised out>)
    at gbx.c:362

(gdb) f 1
#1  0x0000000000430132 in EXEC_loop () at gbx_exec_loop.c:480
480      (*(EXEC_FUNC_CODE)SubrTable[(code >> 8) - 0x28])(code);


Also see attached valgrind log.

Jussi
==3849== Memcheck, a memory error detector
==3849== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==3849== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==3849== Command: gbx3 -p
==3849== Parent PID: 3649
==3849== 
==3849== Conditional jump or move depends on uninitialised value(s)
==3849==    at 0x88E2E40: inflateReset2 (in /lib/libz.so.1.2.3.4)
==3849==    by 0x88E2F2F: inflateInit2_ (in /lib/libz.so.1.2.3.4)
==3849==    by 0x94AF4AF: png_create_read_struct_2 (in /lib/libpng12.so.0.44.0)
==3849==    by 0x94AF646: png_create_read_struct (in /lib/libpng12.so.0.44.0)
==3849==    by 0x72B5C7D: ??? (in /usr/lib/libQtGui.so.4.7.0)
==3849==    by 0x72B66BC: ??? (in /usr/lib/libQtGui.so.4.7.0)
==3849==    by 0x7283752: QImageReader::read(QImage*) (in /usr/lib/libQtGui.so.4.7.0)
==3849==    by 0x7283D1B: QImageReader::read() (in /usr/lib/libQtGui.so.4.7.0)
==3849==    by 0x726F827: QImage::fromData(unsigned char const*, int, char const*) (in /usr/lib/libQtGui.so.4.7.0)
==3849==    by 0x72736FD: QImage::loadFromData(unsigned char const*, int, char const*) (in /usr/lib/libQtGui.so.4.7.0)
==3849==    by 0x60D3DCF: CPICTURE_load_image(QImage**, char const*, int) (gb.form.picture.h:124)
==3849==    by 0x60D46AA: get_picture(char const*, int) (gb.form.picture.h:168)
==3849==    by 0x60D478F: CPICTURE_get(void*, void*) (CPicture.cpp:189)
==3849==    by 0x409553: EXEC_native (gbx_exec.c:1243)
==3849==    by 0x40A57C: EXEC_special (gbx_exec.c:1555)
==3849==    by 0x40B4D0: EXEC_push_array (gbx_exec_push.c:567)
==3849==    by 0x42FF5F: EXEC_loop (gbx_exec_loop.c:521)
==3849==    by 0x409A74: EXEC_function_loop (gbx_exec.c:861)
==3849==    by 0x40A4C4: EXEC_function_real (gbx_exec.c:848)
==3849==    by 0x40A949: EXEC_special_inheritance (gbx_exec.c:1745)
==3849==    by 0x40AD71: EXEC_new (gbx_exec.c:1910)
==3849==    by 0x42FC84: EXEC_loop (gbx_exec_loop.c:823)
==3849==    by 0x409A74: EXEC_function_loop (gbx_exec.c:861)
==3849==    by 0x40A4C4: EXEC_function_real (gbx_exec.c:848)
==3849==    by 0x410290: CLASS_load_without_init (gbx_class_load.c:1181)
==3849==    by 0x4102F7: CLASS_load_real (gbx_class_load.c:1199)
==3849==    by 0x41CD38: GB_GetFunction (gbx_api.c:655)
==3849==    by 0x60BACBF: QT_Init() (main.cpp:635)
==3849==    by 0x60BAD7F: hook_main(int*, char**) (main.cpp:707)
==3849==    by 0x422686: main (gbx.c:325)
==3849== 
==3849== Invalid read of size 4
==3849==    at 0x414B91: SUBR_leave (gbx_subr.c:42)
==3849==    by 0x430131: EXEC_loop (gbx_exec_loop.c:480)
==3849==    by 0x409A74: EXEC_function_loop (gbx_exec.c:861)
==3849==    by 0x40A4C4: EXEC_function_real (gbx_exec.c:848)
==3849==    by 0x4227E4: main (gbx.c:362)
==3849==  Address 0xfffffff7 is not stack'd, malloc'd or (recently) free'd
==3849== 
==3849== 
==3849== Process terminating with default action of signal 11 (SIGSEGV)
==3849==  Access not within mapped region at address 0xFFFFFFF7
==3849==    at 0x414B91: SUBR_leave (gbx_subr.c:42)
==3849==    by 0x430131: EXEC_loop (gbx_exec_loop.c:480)
==3849==    by 0x409A74: EXEC_function_loop (gbx_exec.c:861)
==3849==    by 0x40A4C4: EXEC_function_real (gbx_exec.c:848)
==3849==    by 0x4227E4: main (gbx.c:362)
==3849==  If you believe this happened as a result of a stack
==3849==  overflow in your program's main thread (unlikely but
==3849==  possible), you can try to increase the size of the
==3849==  main thread stack using the --main-stacksize= flag.
==3849==  The main thread stack size used in this run was 8388608.
==3849== 
==3849== HEAP SUMMARY:
==3849==     in use at exit: 7,574,368 bytes in 35,376 blocks
==3849==   total heap usage: 330,738 allocs, 295,362 frees, 201,389,395 bytes allocated
==3849== 
==3849== LEAK SUMMARY:
==3849==    definitely lost: 174,176 bytes in 1,865 blocks
==3849==    indirectly lost: 571,602 bytes in 5,274 blocks
==3849==      possibly lost: 5,269,662 bytes in 18,881 blocks
==3849==    still reachable: 1,558,928 bytes in 9,356 blocks
==3849==         suppressed: 0 bytes in 0 blocks
==3849== Rerun with --leak-check=full to see details of leaked memory
==3849== 
==3849== For counts of detected and suppressed errors, rerun with: -v
==3849== Use --track-origins=yes to see where uninitialised values come from
==3849== ERROR SUMMARY: 917 errors from 2 contexts (suppressed: 18 from 8)
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user

Reply via email to