... one more thing: When wsjt-x comes up (before the crash), the frequency on the radio gets changed by 50Hz up. So if I have e.g. 7074 dialed in, and start the application, I end up with 7074.050 - but then when I manually change the frequency (or test the CAT connection), the software crashes. Is it possible that whatever is done during that initial communication is corrupting the memory setup that then will result in the crash?
Karl Heinz Kremer PDF Acrobatics Without a Net PDF Software Development, Training and More... k...@khk.net http://www.khkonsulting.com On Wed, Nov 27, 2019 at 11:41 AM Karl Heinz Kremer <k...@khk.net> wrote: > Bill, > > yes, it happens every time. Here is what I do: > > 1) Bring up wsjtx with rig configured as FT-857 while flrig is running - > this means the app cannot connect to the serial port and will prompt me to > edit the configuration > 2) Change rig type to flrig (using localhost:12345) > 3) Click on "Test CAT" > 4) That usually causes the problem - if not, change the frequency and that > will cause the problem > > I just did this again, and ended up with the following trace > (slightly different than before): > > [New Thread 0x97072340 (LWP 6044)] > [Detaching after fork from child process 6045] > [Thread 0x98074340 (LWP 6042) exited] > [Thread 0x97873340 (LWP 6043) exited] > free(): double free detected in tcache 2 > > Thread 12 "QThread" received signal SIGABRT, Aborted. > [Switching to Thread 0x95d1e340 (LWP 6038)] > __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 > 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. > (gdb) bt > #0 0xb569cf24 in __GI_raise (sig=sig@entry=6) at > ../sysdeps/unix/sysv/linux/raise.c:50 > #1 0xb5688230 in __GI_abort () at abort.c:79 > #2 0xb56d851c in __libc_message (action=action@entry=do_abort, > fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:181 > #3 0xb56df044 in malloc_printerr (str=<optimized out>) at malloc.c:5341 > #4 0xb56e1098 in _int_free (av=av@entry=0xb57bb7d4 <main_arena>, > p=p@entry=0x95407cb8, have_lock=have_lock@entry=1) at malloc.c:4193 > #5 0xb56e3a04 in _int_realloc > (av=av@entry=0xb57bb7d4 <main_arena>, oldp=oldp@entry=0x95407cb8, > oldsize=oldsize@entry=16, nb=nb@entry=24) at malloc.c:4615 > #6 0xb56e4de8 in __GI___libc_realloc (oldmem=0x95407cc0, bytes=15) at > malloc.c:3222 > #7 0x002466c0 in modeMapAdd () > #8 0x00247478 in flrig_open () > #9 0x00228484 in rig_open () > #10 0x001b44dc in HamlibTransceiver::do_start() () > #11 0x00222bac in TransceiverBase::startup() () > #12 0x00222d0c in TransceiverBase::start(unsigned int) () > #13 0xb5d60ce4 in QMetaCallEvent::placeMetaCall(QObject*) () at > /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 > #14 0xb5d64c68 in QObject::event(QEvent*) () at > /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 > #15 0xb67c9dbc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () > at /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5 > #16 0xb67d22a8 in QApplication::notify(QObject*, QEvent*) () at > /usr/lib/arm-linux-gnueabihf/libQt5Widgets.so.5 > #17 0x03bd6ed8 in () > (gdb) > > > I used to know my way around gdb and debugging on Unix, but I've since > moved to working in different environments, but I am hoping that this is > like riding a bike :) > > Do you have any pointers as to how to create a debuggable version of the > software? > > Thanks, > > Karl Heinz - K5KHK > > Karl Heinz Kremer > PDF Acrobatics Without a Net > PDF Software Development, Training and More... > > k...@khk.net > http://www.khkonsulting.com > > > > On Wed, Nov 27, 2019 at 11:31 AM Bill Somerville <g4...@classdesign.com> > wrote: > >> Hi Karl Heinz, >> >> that stack trace you gave above shows an invalid pointer passed to the C >> library free() function. There is only one free() call in the routine that >> called it and the code looks fine to me, a C-string pointer returned by >> strdup() is being freed and that's fine. I would guess that there is some >> heap memory corruption prior to the free() call. That will probably require >> some extensive debugging to track down. I suspect the issue is wholly >> within Hamlib, is it easy to reproduce? >> >> 73 >> Bill >> G4WJS. >> >> On 27/11/2019 15:36, Karl Heinz Kremer wrote: >> >> I retested with version 2.1.1 and 2.1.2 and I am still getting crashes >> using the flrig interface to my FT857. >> >> Again, if somebody could provide some pointers about how to create a >> debug build that I can step through, I would try to narrow down the >> problem. I found information about how to create a trace file, but I assume >> in this case, I need a bit more information than what the trace file can >> provide. >> >> Karl Heinz Kremer >> PDF Acrobatics Without a Net >> PDF Software Development, Training and More... >> >> k...@khk.net >> http://www.khkonsulting.com >> >> >> >> On Mon, Nov 25, 2019 at 8:34 AM Karl Heinz Kremer <k...@khk.net> wrote: >> >>> On Sun, Nov 24, 2019 at 6:09 PM Karl Heinz Kremer <k...@khk.net> wrote: >>> >>>> [ ... ] I am using wsjt-x 2.0.1 on a Raspberry Pi 4 >>>> >>> >>> My fingers were a bit faster than the brain, I am of course using >>> version 2.1.0 - sorry about that. >>> >> >> _______________________________________________ >> wsjt-devel mailing list >> wsjt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> >
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
