> 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 Minisini ------------------------------------------------------------------------------ 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