Benoît Minisini wrote: >> Am Mittwoch, den 02.12.2009, 20:25 +1100 schrieb Tony: >> >>> Hi Benoit, >>> I have muddled my way through the subversion bit, hopefully correctly >>> and compiled the 2454 version. When opening my application I get the >>> error message "The program has stopped unexpectedly raising signal #11" >>> with the CPU at 100%. If I try to open the wrong ttyUSBx, the application >>> flags this error and behaves correctly, so I would assume that if the >>> ttyUSBx opens OK then the most recent Gambas2 changes have induced the >>> "signal #11" problem. Can you please let me know how to debug further and >>> assist you with your efforts. >>> Thanks and regards, >>> Tony.. >>> Benoît Minisini wrote: >>> >>> Thanks Benoit and all for your speedy replies.. >>> I'm using the serial port in a timing application with 3 laser through >>> beam sensors feeding into the CTS, RI and DSR lines of the serial port. >>> In this mode I don't pass any data, don't really care about flow control >>> and am only interested in the raw status change events. Working this way >>> I haven't noticed gross CPU utilisation after opening the port. The >>> application also uses the UDPsocket to communicate remotely and what I >>> have noticed is that if the serial port does not open correctly e.g. >>> "/dev/tty" wrong and the UDPsocket is open, then there is a large amount >>> of CPU used. Both open correctly and CPU normal. >>> Can you tell me the polling frequency in Gambas2 2.8 ? >>> I would assume that there ore other users of Gambas2 who are using the >>> serial port as a convenient way of passing external events to the >>> application, so maybe some input from them would also be in order. As >>> long as there is a mechanism to replicate the Gambas2 2.8 functionality >>> that I currently use, I'll leave the implementation up to those who know >>> a lot more than myself. If going back to polling, a property to define >>> the frequency would be nice. >>> Thanks again, >>> Tony. >>> >>> >>> Can you try the revision #2454? I think I have found and fix another >>> possible bug, and I'd like to be sure I didn't break anything. >>> >>> Regards, >>> >> Salut Tony, >> >> you will find how to work with gdb there : >> >> go to http://gambas.sourceforge.net/en/main.html >> >> click: Reporting a problem >> >> read : 3. Reporting a crash (a segmentation fault, or a signal #11) >> >> > > And another often more interesting way of debugging is using 'valgrind': > > $ cd /path/to/my/project > $ valgrind --tool=memcheck --num-callers=50 gbx2 > ... > > And then you send me the output written by valgrind. > > Regards, > > Benoît,
I updated to 2454 and have signal 11's too, right away while starting my program. This is the bt: Program received signal SIGSEGV, Segmentation fault. GB_Raise (object=0x11, event_id=0, nparam=0) at gbx_api.c:528 528 OBJECT_REF(object, "GB_Raise"); (gdb) bt #0 GB_Raise (object=0x11, event_id=0, nparam=0) at gbx_api.c:528 #1 0x00b99cd5 in CSerialPort_ReadCallBack (_object=0x11) at CSerialPort.c:175 #2 0x08060997 in raise_callback (wait=<value optimized out>) at gbx_watch.c:425 #3 do_loop (wait=<value optimized out>) at gbx_watch.c:498 #4 0x08060b04 in WATCH_loop () at gbx_watch.c:530 #5 0x08061b72 in main (argc=134739040, argv=0xbffff4e4) at gbx.c:358 (gdb) I'm recompiling without optimizations at this moment, so better backtrace is coming... I only have Flowcontrol = 0 in all of my serial port code. Gambas 2.18.x gb.qt Ubuntu 9.10 Kind Regards, Ron_2nd. ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user