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...
[email protected]
http://www.khkonsulting.com
On Wed, Nov 27, 2019 at 11:31 AM Bill Somerville <[email protected]>
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...
>
> [email protected]
> http://www.khkonsulting.com
>
>
>
> On Mon, Nov 25, 2019 at 8:34 AM Karl Heinz Kremer <[email protected]> wrote:
>
>> On Sun, Nov 24, 2019 at 6:09 PM Karl Heinz Kremer <[email protected]> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
