[Gambas-user] Serial Port Change Events Not Working after Upgrade to Karmic

[Benoît Minisini]

> 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