Project

General

Profile

Actions

Bug #1499

open

PangoWarning: Invalid UTF-8 string passed to pango_layout_set_text()

Added by Jim McCorison about 10 years ago. Updated about 4 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
03/17/2014
Due date:
% Done:

0%

Estimated time:
Chirp Version:
daily
Model affected:
Powerwerx DB-750X
Platform:
MacOS
Debug Log:
I read the instructions above:

Description

Living life on the bleeding edge:
Mac OS X Mavericks 10.9.2
Powerwerz DB-750X
RT Systems Cable
Chirp-daily-20140317

After much struggle I was finally able to download the radio memory into Chirp. As soon as I change the ending number of programming entries that Chirp will use from 25 to something else and click "Go" Chirp crashes. If I immediately save the downloaded file before changing the memory range, then load the file and change the memory range, the same thing happens. The last log entry is:

/Applications/chirp-daily-20140317.app/Contents/MacOS/../Resources/chirp/chirpw:154: PangoWarning: Invalid UTF-8 string passed to pango_layout_set_text() gtk.main()


Files

debug.log (105 KB) debug.log Jim McCorison, 03/17/2014 04:06 PM
stock.img (32 KB) stock.img Jim McCorison, 03/18/2014 04:15 PM
DB-750X Programmer - Stock_.pdf (33.8 KB) DB-750X Programmer - Stock_.pdf Jim McCorison, 03/19/2014 01:52 PM

Related issues

Related to Bug #298: OSX_VX5_pythoncrash>dailybuild_20120906ClosedTom Hayward09/09/2012

Actions
Related to Bug #3769: Crash on RepeterBook QCClosedTom Hayward06/22/2016

Actions
Actions #1

Updated by Tom Hayward about 10 years ago

  • Status changed from New to Blocked

Upload your .img file here please. There's something in there OS X doesn't like, but I'm not sure what it is!

Actions #2

Updated by Jim McCorison about 10 years ago

Attached is the .img file. The same crash occurs with a fresh download from the radio before it is saved to disk.

Actions #3

Updated by Tom Hayward about 10 years ago

  • Status changed from Blocked to In Progress

For some reason, Chirp thinks channels 99-112 are non-empty, but the data in them is unreadable (you haven't actually stored memories here). GTK in OS X chokes on this. Linux reads it just fine. Apparently Chirp is interpreting these memories incorrectly. Maybe this is a different between the Anytone and the Powerwerx. At this point, Chirp assumes the Powerwerx is identical to an Anytone, just with a different badge.

Actions #4

Updated by Jim McCorison about 10 years ago

Either there are issues with my individual radio, or there are differences between the Powerwerx and the Anytone. When I download the radio memory using RT Systems software on a Windows box there are entries programmed into locations 50-56 which do not show up on a download with Chirp. Attached is a print out of the memory locations the RT Systems program retrieved from the radio.

Actions #5

Updated by Dan Smith about 10 years ago

Yes, the PowerWerx radio has some very strange differences from the Anytone. I never finished figuring those out. It works trivially if you only have a few channels, but otherwise, it breaks.

Actions #6

Updated by Jens Jensen about 10 years ago

unsure if this is the same thing I observe on my mac, but I can make it happen if I set a radio field in bitwise to char type, and it has a non ascii char, such as FF, etc. When I attempt to view it in the devel browser it crashes..

Not sure if we have any handlers that can check that data passed is proper format (i.e., UTF-8).. Was thinking this is further up in UI land...

Actions #7

Updated by Tom Hayward about 10 years ago

Yes, this is why it's crashing. However we shouldn't be trying to print those channels in the first place because they are empty.

Actions #8

Updated by Bernhard Hailer about 4 years ago

  • Status changed from In Progress to Feedback
  • Chirp Version changed from 0.3.0 to daily
  • Model affected changed from BX-750X to Powerwerx DB-750X

Unsure - is this still an issue?

Actions

Also available in: Atom PDF