Bug #8

GC intermittently crashes when downloading from PT using USB cradle

Added by Chris Cleeland over 2 years ago. Updated 10 months ago.

Status:Closed Start Date:01/05/2010
Priority:Normal Due date:
Assigned to:- % Done:

0%
Category:-
Target version:-
Operating system:OX X 10.5 Qt Version:
Arch.:x86-64 bit Patch Attached:No
GoldenCheetah Version:developer

Description

I isolated it down to starting the download, then switching to a different app. If I leave GC as the primary app, then the download seems to consistently complete. The "crash" symptoms are that it pops up a dialog about timing out while writing 'q', then I get a bad access in the download thread.

Here's one example of stack traces for threads when this occurs, but the stack traces are not consistent. Thread 1's backtrace is different, which makes it sound like a data corruption issue.

Here's the backtraces from all the threads when when GC crashes after
a failed PT download:

(gdb) thread apply all bt

Thread 5 (process 10165 thread 0x60cb):
#0 0x941df2ce in semaphore_wait_signal_trap ()
#1 0x942112c6 in _pthread_cond_wait ()
#2 0x94256539 in pthread_cond_wait ()
#3 0x17a95943 in EventWait ()
#4 0x17a961d1 in write_thread ()
#5 0x94210155 in _pthread_start ()
#6 0x94210012 in thread_start ()

Thread 4 (process 10165 thread 0x5d2f):
#0 0x95f1903a in IODispatchCalloutFromCFMessage ()
#1 0x95f190b6 in IODispatchCalloutFromMessage ()
#2 0x93f0aff5 in __CFMachPortPerform ()
#3 0x93f2f6b8 in CFRunLoopRunSpecific ()
#4 0x93f2faa8 in CFRunLoopRunInMode ()
#5 0x17aa0f88 in usb_bulk_transfer ()
#6 0x17aa137e in usb_bulk_read ()
#7 0x17a94693 in reader_thread ()
#8 0x94210155 in _pthread_start ()
#9 0x94210012 in thread_start ()

Thread 3 (process 10165 thread 0x6507):
#0 0x941e646e in __semwait_signal ()
#1 0x942113e6 in _pthread_cond_wait ()
#2 0x94210dcd in pthread_cond_wait$UNIX2003 ()
#3 0x96061b32 in glvmDoWork ()
#4 0x94210155 in _pthread_start ()
#5 0x94210012 in thread_start ()

Thread 2 (process 10165 thread 0x1103):
#0 0x942163ca in select$DARWIN_EXTSN$NOCANCEL ()
#1 0x94264261 in select ()
#2 0x0188de98 in QProcessManager::run ()
#3 0x017ecf9b in QThreadPrivate::start ()
#4 0x94210155 in _pthread_start ()
#5 0x94210012 in thread_start ()

Thread 1 (process 10165 thread 0x10b):
#0 0x941df2c2 in semaphore_wait_trap ()
#1 0x942567fd in pthread_join ()
#2 0x17a9a313 in FT_Close ()
#3 0x00006a17 in D2XX::close (this=0x17b6f7b0) at
/Users/cleeland/Source-Tools/GoldenCheetah/src/D2XX.cpp:146
#4 0x00006a47 in D2XX::~D2XX (this=0x17b6f7b0) at
/Users/cleeland/Source-Tools/GoldenCheetah/src/D2XX.cpp:105
#5 0x00008974 in boost::checked_delete<D2XX> (x=0x17b6f7b0) at
checked_delete.hpp:34
#6 0x00009318 in boost::detail::sp_counted_impl_p<D2XX>::dispose
(this=0x17b6f820) at detail/sp_counted_impl.hpp:78
#7 0x00007d26 in boost::detail::sp_counted_base::release
(this=0x17b6f820) at detail/sp_counted_base_gcc_x86.hpp:145
#8 0x00007d62 in boost::detail::shared_count::~shared_count
(this=0x17b50414) at detail/shared_count.hpp:217
#9 0x00008872 in boost::shared_ptr<CommPort>::~shared_ptr
(this=0x17b50410) at shared_ptr.hpp:169
#10 0x00008a93 in QVector<boost::shared_ptr<CommPort> >::free
(this=0x17b500c4, x=0x17b50400) at qvector.h:436
#11 0x00008af9 in QVector<boost::shared_ptr<CommPort> >::~QVector
(this=0x17b500c4) at qvector.h:119
#12 0x0010d7a2 in DownloadRideDialog::~DownloadRideDialog
(this=0x17b50090) at DownloadRideDialog.h:28
#13 0x018b6f2c in QObject::event ()
#14 0x00c9a501 in QWidget::event ()
#15 0x00c434bf in QApplicationPrivate::notify_helper ()
#16 0x00c4943b in QApplication::notify ()
#17 0x017cb492 in QCoreApplication::notifyInternal ()
#18 0x018aa751 in QCoreApplicationPrivate::sendPostedEvents ()
#19 0x00bef0ce in
QEventDispatcherMacPrivate::postedEventsSourcePerformCallback ()
#20 0x93f2f3c5 in CFRunLoopRunSpecific ()
#21 0x93f2faa8 in CFRunLoopRunInMode ()
#22 0x91f212ac in RunCurrentEventLoopInMode ()
#23 0x91f20ffe in ReceiveNextEventCommon ()
#24 0x92064377 in ReceiveNextEvent ()
#25 0x00bef789 in QEventDispatcherMac::processEvents ()
#26 0x018a8441 in QEventLoop::processEvents ()
#27 0x018a866d in QEventLoop::exec ()
#28 0x018aa9ce in QCoreApplication::exec ()
#29 0x0010b122 in main (argc=1, argv=0xbffff280) at
/Users/cleeland/Source-Tools/GoldenCheetah/src/main.cpp:133

This is the code at the failed spot:

0x941df2b8 <+0000> mov $0xffffffdc,%eax
0x941df2bd <+0005> call 0x941dfad4 <_sysenter_trap>
0x941df2c2 <+0010> ret
0x941df2c3 <+0011> nop

with the PC ready to run the RET. The value in %eax is suspicious: 0xe.

History

#1
Updated by Sean Rhea over 2 years ago

My GC stack traces never have more than one thread. What version of the FTDI drivers are you using?

#2
Updated by Chris Cleeland over 2 years ago

bobke2:Samples cleeland$ ls -l /usr/local/lib/libftd2xx.*
-rwxr-xr-x@ 1 root wheel 212916 Dec 31 21:10 /usr/local/lib/libftd2xx.0.1.7.dylib*
lrwxr-xr-x 1 root wheel 36 Dec 31 21:10 /usr/local/lib/libftd2xx.dylib@ -> /usr/local/lib/libftd2xx.0.1.7.dylib

I just noticed that the lib has an extended attribute, so I checked and it's this:

$ xattr -l /usr/local/lib/libftd2xx.0.1.7.dylib
com.apple.quarantine: 0000;4b3d672e;Safari.app;075DC243-710F-4AB7-940C-9D4940B9E4D6|com.apple.Safari

I wonder if that has any effect? Doubtful, but I've removed it anyway and will update the bug if this has an effect.

$ sudo xattr -d com.apple.quarantine /usr/local/lib/libftd2xx.0.1.7.dylib

#3
Updated by Jamie Kimberley over 2 years ago

  • Status changed from New to tempfix

I've updated the status to "tempfix" as we have a current workaround; use the 0.1.6 version of the drivers.

The 0.1.6 version of the drivers can be found here: http://bugs.goldencheetah.org/attachments/download/1/Universal_D2XX0.1.6.dmg

Chris, thanks for looking into this. Hopefully you can track down the source of the problem and resolve it.

#4
Updated by Jamie Kimberley over 1 year ago

  • Patch Attached set to No

A little update from a benevolent poster to our mailing list:

I have been working on an Qt application that also uses libftd2xx. It
crashed randomly on Mac OS and I found this bug report while searching
for a solution. The traceback looks similar and the 0.1.6 version
solved the issue for me as well. So thank you for pointing me in the
right direction :)

However, there is a better way to solve this. It's actually explained
in the ReadMe file for the driver. The problem occurs in multithreaded
applications only. You need to create an ftd2xx.cfg file in /usr/
lib/, /usr/local/lib/, or in your current working directory. The file
should look like this:

[Globals]
ConfigFlags=0x40000000

Thanks lars.

Anyone care to look into this more deeply? Is this something that we need to do at compile time, or does each user need to add a ftd2xx.cfg file to their system?

#5
Updated by Mark Liversedge 10 months ago

  • Status changed from tempfix to Closed

I'm closing this, since there is no fix to apply to GC.

Also available in: Atom PDF