[Gambas-user] Serial Port Change Events Not Working after Upgrade to Karmic
Tony
ajw4me at ...466...
Thu Dec 3 02:06:07 CET 2009
Benoit,
Here is the output of valgrind as requested. I hope it helps.
Regards,
Tony..
$ valgrind --tool=memcheck --num-callers=50 gbx2
==2404== Memcheck, a memory error detector
==2404== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==2404== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright
info
==2404== Command: gbx2
==2404==
/dev/ttyUSB0
19200
0
8
1
1
1
==2404== Invalid read of size 4
==2404== at 0x535C586: CSerialPort_CallBack (CSerialPort.c:120)
==2404== by 0x4663A21: CWatch::write(int) (CWatch.cpp:143)
==2404== by 0x4663885: CWatch::qt_invoke(int, QUObject*)
(CWatch_moc.cpp:91)
==2404== by 0x493C359: QObject::activate_signal(QConnectionList*,
QUObject*) (in /usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x493E1E3: QObject::activate_signal(int, int) (in
/usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x4C9BBFF: QSocketNotifier::activated(int) (in
/usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x495B166: QSocketNotifier::event(QEvent*) (in
/usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x48D74B6: QApplication::internalNotify(QObject*, QEvent*)
(in /usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x48D842A: QApplication::notify(QObject*, QEvent*) (in
/usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x463A5E2: MyApplication::notify(QObject*, QEvent*)
(main.cpp:354)
==2404== by 0x48CC1E3: QEventLoop::activateSocketNotifiers() (in
/usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x488207D: QEventLoop::processEvents(unsigned int) (in
/usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x463A70B: MyEventLoop::processEvents(unsigned int)
(main.cpp:247)
==2404== by 0x48F04AF: QEventLoop::enterLoop() (in
/usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x48F0355: QEventLoop::exec() (in /usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x48D7B0E: QApplication::exec() (in
/usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x4639D57: hook_loop() (main.cpp:542)
==2404== by 0x8061B71: main (gbx.c:358)
==2404== Address 0x31 is not stack'd, malloc'd or (recently) free'd
==2404==
==2404==
==2404== Process terminating with default action of signal 11 (SIGSEGV)
==2404== Access not within mapped region at address 0x31
==2404== at 0x535C586: CSerialPort_CallBack (CSerialPort.c:120)
==2404== by 0x4663A21: CWatch::write(int) (CWatch.cpp:143)
==2404== by 0x4663885: CWatch::qt_invoke(int, QUObject*)
(CWatch_moc.cpp:91)
==2404== by 0x493C359: QObject::activate_signal(QConnectionList*,
QUObject*) (in /usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x493E1E3: QObject::activate_signal(int, int) (in
/usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x4C9BBFF: QSocketNotifier::activated(int) (in
/usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x495B166: QSocketNotifier::event(QEvent*) (in
/usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x48D74B6: QApplication::internalNotify(QObject*, QEvent*)
(in /usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x48D842A: QApplication::notify(QObject*, QEvent*) (in
/usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x463A5E2: MyApplication::notify(QObject*, QEvent*)
(main.cpp:354)
==2404== by 0x48CC1E3: QEventLoop::activateSocketNotifiers() (in
/usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x488207D: QEventLoop::processEvents(unsigned int) (in
/usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x463A70B: MyEventLoop::processEvents(unsigned int)
(main.cpp:247)
==2404== by 0x48F04AF: QEventLoop::enterLoop() (in
/usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x48F0355: QEventLoop::exec() (in /usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x48D7B0E: QApplication::exec() (in
/usr/lib/libqt-mt.so.3.3.8)
==2404== by 0x4639D57: hook_loop() (main.cpp:542)
==2404== by 0x8061B71: main (gbx.c:358)
==2404== If you believe this happened as a result of a stack
==2404== overflow in your program's main thread (unlikely but
==2404== possible), you can try to increase the size of the
==2404== main thread stack using the --main-stacksize= flag.
==2404== The main thread stack size used in this run was 8388608.
==2404==
==2404== HEAP SUMMARY:
==2404== in use at exit: 1,958,423 bytes in 15,402 blocks
==2404== total heap usage: 102,525 allocs, 87,123 frees, 7,712,919 bytes
allocated
==2404==
==2404== LEAK SUMMARY:
==2404== definitely lost: 6,916 bytes in 28 blocks
==2404== indirectly lost: 12,892 bytes in 633 blocks
==2404== possibly lost: 175,810 bytes in 721 blocks
==2404== still reachable: 1,762,805 bytes in 14,020 blocks
==2404== suppressed: 0 bytes in 0 blocks
==2404== Rerun with --leak-check=full to see details of leaked memory
==2404==
==2404== For counts of detected and suppressed errors, rerun with: -v
==2404== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 123 from 11)
Segmentation fault
$
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 [1]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,
References
1. http://gambas.sourceforge.net/en/main.html
More information about the User
mailing list