0.1.4 crashing on start-up

[David Armbruster]

Brand new user, hello everyone!

Installed 0.1.3, which went fine and app started.  Was able to configure a Mobilinkd TNC3 and a USB GPS puck.  When to go live and that caused app to crash.  Then it wouldn't start again.

At that point I went ahead and installed 0.1.4 and it won't start either.  Looking through log files now.  I attached the most recent to a Bitbucket ticket but don't have much more yet to give a detailed report. 

Will start looking for a pref or config file.  LMK if you'd like anything specifically at this point, Weston. 

Thanks!

David, AC0VH

[David Armbruster]

Deleted:

~\Library\Application Support\com.w8wjb.QTH\qth.sqlite3

App starts and created a new one.  Moving forward!

David

[Kevin Reeve]

Installed 0.1.4  working good.   

Kevin N7RXE

[Weston Bustraan]

Hmm, I wonder if you received a packet that QTH choked on. If it was fixed when you deleted that file, that would seem likely.

Just as an FYI for everyone, QTH uses these standard locations for data:

Preferences are in: ~/Library/Preferences/com.w8jb.QTH.plist

- If you trash this, like all Mac apps, you will reset everything in Preferences and Connections to "factory defaults"

All packets that you receive are stored in: ~\Library\Application Support\com.w8wjb.QTH\qth.sqlite3

- This is a sqlite database, for any of you that know what that is and want to poke around. SQLiteStudio is my favorite tool for this

- If you trash it, you will effectively clear your packet history. There is also a command on the menu that will do that also.

The log file is in: ~\Library\Logs\com.w8wjb.QTH/qth.log

- There is a menu item that opens this file in Console.app

If you run into a crash like this, I would suggest moving the database out of the way, and see if QTH starts, similar to what David did. If it fixes the issue, please send me the qth.sqlite3 file so that I can investigate.

David, do you know whether the file is in your trash? If it is, can you attach it to the bug report or mail it to me?

- Wes, W8WJB

--
You received this message because you are subscribed to the Google Groups "qthapp-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qthapp-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qthapp-users/258bfeec-a1dd-400f-b6dd-f9f7436fd329n%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Armbruster]

I'm sorry Wes, but that file is gone.  I've actually had to delete it a few times, along with the plist file.  Looks like I'm having some conflict trying to transmit with the TNC3.

Right now it's stable just listening to traffic so I'm letting it do that for a while.  There's a couple of minor things I notice with respect to that (nothing major, just UI stuff you may know about).

I did attach the qth.log to the Bitbucket ticket, although it's not very helpful I don't think.  It shows the attempt to transmit/beacon (such as DEBUG APRSManager.transmit():174 - Posting packet aprsPacketTransmit) but nothing more about the crash that occurs immediately after that.  I'll start a new log and kick a TX to get a crash and attach a clean set of files.

David

[David Armbruster]

Update - my QTH is working!

I removed all the config files, deleted the TNC3 Bluetooth profile and started from a clean point with a fresh install and new BT profile.  Walking through building the configuration again I can get QTH to crash by not setting a symbol, so it seems likely that my issue had to with a malformed APRS frame. 

Perhaps the symbol but at this point I can't say for sure, could have been in the position format, source, comment.  Hard to say since packets were not being transmitted but choking going into APRSManager.transmit() and I'm aware of any good logging for that without actually stepping through the code.

At this point it's been stable running for a couple of hours, continuously receiving and transmitting beacons every 15 minutes on the air.

David, AC0VH

[Weston Bustraan]

I think I found what was causing the crash. Based on the crash report, it was happening when QTH was attempting to report an error using a desktop notification. This was only happening on 10.14 because of an API difference between macOS 10.14 to 10.15. It should be fixed in 0.1.5. This would likely explain why it was working for Kevin N7RXE with the TNC3 but not you.

- Wes, W8WJB

To view this discussion on the web visit https://groups.google.com/d/msgid/qthapp-users/328cdfad-36c1-4508-a391-ef2f5d7764c3n%40googlegroups.com.

[David Armbruster]

Wes,

Updated to 0.1.5 and went through the same steps, including not setting a symbol.  With no symbol set the beacon does not transmit but app also does not crash as it did with 0.1.4.  So appears that you were correct all along that an invalid frame must have been causing the crash with Mojave and the revisions correctly trap them.  So far everything's running and seems stable for me now.

David, AC0VH

[Weston Bustraan]

Yes, I did some looking into it; it appears that the invalid frames were your own Mic-E beacons, due to an edge case that I hadn't considered. I will have a fix available this evening.

When QTH.app starts up, it will back up in time and replay all the packet history up until the present moment. This is done so that you can restart QTH.app and pick right back up with the map the way it was.

I knew from the log message that mentioned APRSHistoryDAO that something was happening when attempting to parse the historical packets. So, I found the packet in question and noticed that it is a Mic-E packet.

The error message basically means that the parser hit the end of the data before parsing a complete packet. Looking at the Mic-E data format, the last two characters are your symbol table and symbol code. In your case, it was truncated; the symbol was missing. As you found, once you set the symbol, the packets are now correctly formed and you shouldn't get the error message any more. I am going to add a check that will prevent QTH from transmitting if a symbol is not selected.

It's funny; I've been working with APRS clients for so long now, that it is an ingrained habit to always set my callsign, ssid, and symbol as part of setting up a new client, but I hadn't considered that that is not necessarily an intuitive thing. That's why this beta test is so incredibly useful; it exposes different ways of thinking.

Question for the group: Should I take a page from YAAC's book and implement a "New Station Configuration Wizard" that walks you through initial setup when you start up QTH for the first time?

- Wes, W8WJB

To view this discussion on the web visit https://groups.google.com/d/msgid/qthapp-users/b38ce4d4-f78e-4572-b2c4-da1e3ea0824cn%40googlegroups.com.

[David Armbruster]

A wizard is fine.  I don't use YAAC extensively so I can't say how it compares.  I use Xastir and APRSISCE mostly, which take the approach of providing more than sufficient rope. 

Either way perhaps you could have a default in the field to make it failsafe?  Xastir, as an example, I think defaults with forward slash and an x < /x > which is the old xAPRS symbol, e.g. the X11 logo.  Or the APRS spec has generic ones.

Two forward slashes <//> is a red dot 

Forward slash and period </.> is a red x

Back slash and period <\.> is a question mark

David, AC0VH

[Weston Bustraan]

As a general rule, barring a bug I'm not aware of yet, the parser should not crash on malformed packets. In this case, it was just too verbose in logging the error. The parser already runs in a separate thread. In fact, each connection has its own thread. Because of this, I have the logger framework set up to report anything logged at the "error" level as a notification to the user; all other levels just get sent to the log file. The place where this error originated from, though, was while it was re-reading packets from the database and should have been logging at a level lower than error. Any incoming malformed packet should get dropped before it ever makes it to the database. This was an unique case because the packet did not originate from an external source, but rather it was a packet that QTH created. The assumption is that QTH should never generate a malformed packet. But of course, there's always the chance for a bug, which this was. That's what this beta test is for - to squash the bugs.

With regards to a wizard, there are already places to configure all the necessary configuration in the Preferences and there's a help article that describes station setup, but I'm wondering if I need to be a bit more "in your face" about it and present a wizard to help walk through it. In YAAC terms, Andrew has both a "configuration wizard" and an "expert config", What I have right now is akin to the "expert config". 

You don't tend to see a lot of "wizards" in the Mac world. Some things, like when installing macOS itself, do have them. When you're installing the OS for the first time, you're prompted for things like WiFi settings and iCloud credentials. But other things, even something as complex as iMovie, just dumps you into the user interface and you're expected to either know what you're doing or muddle your way through it.

This is the discovery process - I'm learning how people (who aren't me) discover how to use an app like this. Things that seem intuitive to me, may be absolutely opaque to others. In general, I will likely take some cues from Mail.app; this is an example of an Apple app that you basically can't do much with unless you first fill in a few (sometimes technical) details.

I'm tempted to default the symbol to /M, which is the Apple logo that was originally used for MacAPRS. I don't imagine there are very many people running MacAPRS anymore.

- Wes, W8WJB

On Mon, Feb 22, 2021 at 10:35 AM Steve Dimse <st...@dimse.com> wrote:

> On Feb 22, 2021, at 9:37 AM, Weston Bustraan <wbus...@gmail.com> wrote:
>
> The error message basically means that the parser hit the end of the data before parsing a complete packet. Looking at the Mic-E data format, the last two characters are your symbol table and symbol code. In your case, it was truncated; the symbol was missing. As you found, once you set the symbol, the packets are now correctly formed and you shouldn't get the error message any more. I am going to add a check that will prevent QTH from transmitting if a symbol is not selected.

You might want to take a wider view of this. Though the vast majority of information on the APRS IS is valid, given the volume it is not surprising that pretty much every possible mangled packet appears at some point. Sometimes it is a TNC config issue (PASSALL ON), sometimes programmer error (you would not believe what kind of garbage is fed into the system by new programmers), sometimes user config issues like this, sometimes cosmic ray bit errors or some other random problem. But they happen every hour of every day, and they should never crash a client.

You might consider implementing a mechanism to put the parser into a separate process and implement a way for the main code to detect when a packet has crashed the parser, restart the parser and skip the bad packet. Or if you want to keep it in a single thread, you need to be very robust, and for example be sure a string is long enough before you grab a character so the crash does not happen. findU does both, and even after 20 years of fixing edge cases it still crashes every week or two and is automatically restarted. Sometimes it starts crashing many times a day, that is a sign someone is sending trash and I can use the log files to track it down, make my parser more robust and perhaps yell at whoever is sending garbage.

> Question for the group: Should I take a page from YAAC's book and implement a "New Station Configuration Wizard" that walks you through initial setup when you start up QTH for the first time?
>

Yes, it is not just YAAC, most clients do this. You should definitely ensure all needed fields are filled with valid data before building a packet, even one sent internally.

Steve K4HG

[David Armbruster]

I think /M would be pretty cool.  It's fair IMO to call QTH the only
Mac-native APRS client.  AFAIK MacAPRS development stopped in 2006.  The
version that's out there is 32-bit Carbon and I think would last run
maybe on 10.12 or 10.13. It won't run on 10.14 Mojave at all.  Strictly
speaking 10.8 would be the last OS X that supported Carbon.

Going under hood doesn't bug me and I don't generally like having my
hand held.  But I knew better and walking me through critical fields on
first run would have obviously saved some grief.  With a client like
Xastir a wiki or FAQ is sufficient but for QTH rich help and wizards
seem completely appropriate.

David, AC0VH