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