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

[Ron]

Ron wrote:
> 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.
>

Hmm... recompiling complete Gambas source without optimization flag 
didn't result in a more verbose output, and I don't want to recompile 
libqt or things like that.

Regards,
Ron_2nd.