Bug #4791
openMacOS daily-20170501 repeatable crash
0%
Description
I just installed chirp-daily-20170501.app to try. I am attempting to
copy setups from one Leixen VV-898E radio into several others.
However, a fraction of a second after the screen fills with the data
from the radio, Chirp unexpectedly quits, and I'm given the opportunity
to send a report to Apple.
My system is:
Macbook Air 11" (MacBookAir6,1)
MacOS X 10.11.6 (15G1421)
4GB RAM
The last line in .chirp/debug.log reads:
/Users/username/Applications/chirp-daily-20170501.app/Contents/MacOS/../Resources/chirp/chirpw:143:
PangoWarning: Invalid UTF-8 string passed to pango_layout_set_text()
gtk.main()
I'm using the osx-pl2303-installer.pkg for my serial driver. This is
currently the only radio for which I have a programming cable--it's the factory-supplied cable.
Updated by Brian McLaughlin over 7 years ago
I'll just add to this. I experience the same crash. The build prior to the May 1 build defaulted to showing channels 1 through 25 (my template has 715 channels in it). When I change the range to view to display any channels over 650, it crashes. I can display 1 through 650 without problem. I can display 600-650 without problem. When I change it to 600-651, it crashes.
The May 1 build defaults to showing all channels (I think it's showing as many as the radio will hold - a PowerWerx db-750). So I don't know if the problem has to do with trying to display high channel numbers or perhaps trying to display an unprogrammed channel. Although my channel 651 is programmed, so maybe it's just the number - I don't know.
Hopefully that's another data point for you for this bug. I'm anxious to get a fix.
Thanks.
Updated by Tom Hayward over 7 years ago
This sounds like an issue I observed when using a Yaesu VX5. There were some unprintable characters in a memory channel name and that triggered a bug in PyGTK that caused it to crash. We worked around that by forcing the VX5 driver not to return unprintable characters in channel names.