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

[Ron]

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.