|
Hi, I have reinstalled Xastir after many years and I get stuck regarding the missing map at program start. Any suggetsion? TKS, PY1ZRJ |
Replies: 16 comments 32 replies
|
Wow, that's a failure I've never seen before. We're definitely going to need more information to diagnose that behavior. What OS? How did you install Xastir? Xastir stores all the information about the map index and what map you've got selected in the "~/.xastir/config/" directory. Does this directory exist? (it should be created and populated when you run Xastir for the first time). It should contain your xastir.cnf configuration file, a file called map_index.sys, and a file called selected_maps.sys (among others). Check to see if these files are being created when you save config, and check what they contain. Xastir is supposed to index all maps the second it starts up the first time, and mine does when I start it fresh. So something is going wrong in that process and we'll have to figure out what is happening before we can figure out how to make it stop. |
|
Also, how are you starting Xastir? From the command line or from a desktop icon? The more information you can give the better. I can't reproduce this failure, so until I can it'll be difficult to say how to get your issue addressed. |
|
Hello @tvrusso and thank you for your feedback! Copy/Paste here some details maybe useful for your analysis. Linux version: "openSUSE Tumbleweed 20260520" marco@linux-turion64:~> ls -la .xastir/ marco@linux-turion64: I've tried several ways to start xastir but the result is the same: empty window at start, I need to reindex all maps and select the one I want. |
|
Well, nothing looks wrong with When you start Xastir from the command line, do you see any error messages? Could you also post your xastir.cnf file? |
|
You also say you tried "several ways to start xastir" but not what ways those are. Could you be more specific? |
|
Hi Tom, When I start xastir from console, I don't see errors which be related this missing map issue. Here below my current xastir.cnf: When I said "several ways", I meant doing things as delete cache, remove sys files, changing the default map (the one selected)... Many different ways to check if the program showing the map at reboot, including file permissions and so on. Thanks and regards, Marco |
|
This is truly puzzling, as your map index looks fine, I don't see any weird issues in your config file, and clearly Xastir is creating the map index and selected map files, just not reading them in when you start up. You have "index maps on startup" set, so it should automatically index maps when you start. Do you see any error messages at all when Xastir starts up? You say "I don't see errors which be related this missing map issue." but if there are any messages at all it could be a hint to what's going on. A screen shot of the terminal window showing what you see when you start Xastir from the console might help. Might not, but it's worth seeing. Since I can't reproduce this failure, it is very hard for me to suggest how you can get around it or how to debug it. Are you at all comfortable with poking around in source code to add debug statements to see what's happening? There's one spot in main.c that reads in the index file from an existing file by calling a single function in maps.c that does that reads the file. If we could get some debug information out of those steps we might be able to understand why your Xastir is starting up without recognizing that there's already a map index and selected map. |
|
I'm very sorry for my late answer Tom, apologies! This is the output from console when launching xastir: marco@linux-turion64:~/alpha/CqrlogAlpha> xastir Built-in map types: Support for these additional map types has been compiled in: index_restore_from_file: auto_maps field incorrect 2 in map name: index_restore_from_file: auto_maps field incorrect 2 in map name: index_restore_from_file: auto_maps field incorrect 2 in map name: index_restore_from_file: auto_maps field incorrect 2 in map name: index_restore_from_file: auto_maps field incorrect 2 in map name: index_restore_from_file: auto_maps field incorrect 2 in map name: index_restore_from_file: auto_maps field incorrect 2 in map name: I'm not a developer nor a skilled coder but maube I could do some guided debugging if you think being useful. Best 73 de Marco PY1ZRJ |
|
Ok, this is really strange, because Xastir is saying it's trying to migrate from an old map_index.sys file format to a new format, which means you've got a really old map index file --- that file format was obsolete in 2003. The fact that you're getting this, even after having repeatedly deleted old .sys files, suggests something really strange about your set-up. No new version of Xastir would have recreated a map_index.sys file in that old format, and the fact that it continues to find one over and over again means something very strange is going on. Note that it's telling you it's found an old format with missing entries, then it tells you it's migrating to the new format --- what is supposed to happen then is that it writes out a NEW map_index.sys in the new format to REPLACE the old one. If you're still getting this this long after trying to get this working, somehow the old one is not getting discarded. Could you please issue the following command in your home directory? Let's see if somehow you've got multiple config directories set up somehow and Xastir is finding the wrong one. If you look at the file src/maps.c, find the function "index_restore_from_file(void)". At the top it should look like this: That commented out fprintf is completely pointless as it stands, but if you replace it to read: (that is, take off the two slashes from the beginning to uncomment it, and change it to print the name of the file it's trying to read), then recompile and reinstall, then Xastir will actually print out what file it's trying to read from when it starts. Knowing what it says should help track down this issue. |
|
You also have that "ENOENT ERROR" going on, but that's emitted by the interface code so something is wrong with your interfaces as well --- but that's another issue. My guess is that you do not actually have a device called "/dev/kisstnc" and that your device 2 is failing to initialize. But one thing at a time --- let's figure out this map index problem. |
|
You also have some strangeness in your .xastir/config/xastir.cnf file that suggests it might be really old and that you once had installed a version of Xastir from a system package: This is an odd mix of paths that have /usr/share and /usr/local/share, which isn't normal. You said at the beginning that you're starting to use Xastir again after many years --- did you by any chance keep your .xastir directory around all those years? Before we go further down this path, could you please try this: This will make Xastir start from scratch as if it had never run on your system before, and it will create a brand new config file and map index. You will, of course, have to re-enter all your station information (position, type, etc.) and create new interfaces, but this will at least narrow down the problem somewhat. I said I couldn't spot problems in your config file, but clearly I overlooked something. Moving your old config directory out of the way and starting fresh should eliminate a lot of possible problems. |
|
Yeah Tom, Here it goes the find output for map_index.sys: marco@linux-turion64:~> find . -name map_index.sys Before to compile the xastir from the Git repository, I tried the rpm package of it, which install the stuff into /usr/share. So maybe this is the point! I would prefer to avoid to "mv .xastir" since I would have to redo the settings, then if possible I would like to cancel everything from /usr/share path because now I'm using xastir from /usr/local as xastir directory. Thanks for your inputs! Regards, Marco |
|
I understand not wanting to redo all the settings, especially if you've made a lot of customizations, but by moving the .xastir directory out of the way, at least temporarily, you can at least see whether the map indexing works correctly and identify a mangled config as the problem (or not). If it doesn't help, you could always move it back. Are you absolutely sure you removed the version of Xastir from the RPM before you installed Xastir from the git repo? If you are dead-set against moving the .xastir directory out of the way, then you need to hand-edit the config file and replace all the /usr/share stuff with /usr/local/share, but the potential for messing that up is higher than just starting from scratch. |
|
Hello Tom, I renamed .xastir/config/xastir.cnf and deleted all cnf.1,2,3... This is the output of xastir from console: marco@linux-turion64:~> xastir Built-in map types: Support for these additional map types has been compiled in: index_restore_from_file: auto_maps field incorrect 2 in map name: index_restore_from_file: auto_maps field incorrect 2 in map name: index_restore_from_file: auto_maps field incorrect 2 in map name: index_restore_from_file: auto_maps field incorrect 2 in map name: index_restore_from_file: auto_maps field incorrect 2 in map name: index_restore_from_file: auto_maps field incorrect 2 in map name: |
|
Then I reindexed maps and selected mapnik geo map saved config and restarted and ones again no maps at all at startup! |
|
Attaching the new xastir.cnf produced. |
|
And finally I edited current xastir.cnf, correcting all the wrong paths from /usr/share, to /usr/local/share, but no automatic map loading at startup yet. |
|
OK, so that clearly indicates that the problem is NOT an old-format map index, and that somehow Xastir is incorrectly reading your map index and getting confused into thinking it's an old format. That is really puzzling, and I wonder if it is somehow a locale issue screwing up the scanf. Could you please try this: to start Xastir. That will force it into a locale that shouldn't confuse it. That could have other annoying effects on the code, but if doing that causes those messages about incorrect values for auto_maps to go away and start letting the map index be read properly, we'll at least know where to look for the real problem. |
|
So, the problem here is that somehow Xastir is incorrectly reading in your map_index.sys file and mistakenly deciding that it's an old format (a format that was obsolete in 2003), even though it ISN'T. It is then trying to read the lines in the file using a format string that is expecting only 4 long integers and 3 shorter, the last of which is an automap setting, followed by the file name. But the modern format is 4 long integers and 6 shorter, followed by the file name. If you look at the error messages, it's including those last 3 integer fields in the file name. So somehow Xastir is getting really confused reading your map_index.sys file. My best guess is that there's a locale issue (which can change how the C function "scanf" and its friends like sscanf actually function). This was a problem in Xastir a long time ago and we thought we had it nailed by setting the locale appropriately ourselves, but there might be some edge cases that aren't getting handled properly. So please try the "env LANG=C xastir &" thing before anything else just to see if this behavior goes away. If it does, there might be more we have to do inside Xastir to force the locale. If it doesn't help, I am really confused what might be going on for you. |
|
And if using the LANG thing doesn't fix anything, the only path forward will be for you to insert some debug statements into the function that processes the map index file. If that becomes necessary, I'll have to walk you through where to insert them and what to insert. |
|
marco@linux-turion64:~> env LANG=C xastir Built-in map types: Support for these additional map types has been compiled in: index_restore_from_file: auto_maps field incorrect 2 in map name: index_restore_from_file: auto_maps field incorrect 2 in map name: index_restore_from_file: auto_maps field incorrect 2 in map name: index_restore_from_file: auto_maps field incorrect 2 in map name: index_restore_from_file: auto_maps field incorrect 2 in map name: index_restore_from_file: auto_maps field incorrect 2 in map name: |
|
OK, so that confirms it isn't a locale issue, either. This is getting weird. We'll have to get you to insert debugging statements in the function Please stop clicking the "mark as answer" button on every response you make. That button is meant to flag a comment as the definitive answer to an issue, so that readers can find "the" answer quickly. So far, there is no definitive answer to this question, so I have to keep unmarking your comments. |
|
Sorry for clicking! |
|
OK, let's start here, this should at least tell us what Xastir thinks is going on when it's reading your map_index.sys file. Edit the file src/maps.c, and find the function Insert the following line right before the comment "We're upgrading..." So now it'll look like: Now rebuild and reinstall Xastir and try running it. You should see all of those same error messages, but with additional information printed right before them. Please post all of what you see. |
|
I edited the /src/map.c as suggested then I ran these sequence of comands: make clean;make -j3 2>&1 | tee make.log Then started xastir but I dont see nothing different: marco@linux-turion64:~/Xastir/Xastir_Git/Xastir/build> xastir Built-in map types: Support for these additional map types has been compiled in: |
|
This is not showing any of the new output we just added, and ends before any of the errors you were seeing before. Did Xastir crash? |
|
No, running normally (without maps) |
|
Then it should at least have output all the same error messages it did before, and your output doesn't show anything at all. Please cut/paste all of the output that Xastir produces. |
|
Post the output of this:
xastir -V
Should show the version number of xastir. I'm wondering if you somehow are running an old binary or something instead of the new one you just built.
Kevin
KB9MQU
…On Thursday, June 4th, 2026 at 15:07, mcalistri ***@***.***> wrote:
I edited the /src/map.c as suggested then I ran these sequence of comands:
make clean;make -j3 2>&1 | tee make.log
sudo make install
Then started xastir but I dont see nothing different:
***@***.***:~/Xastir/Xastir_Git/Xastir/build> xastir
Built-in map types:
gnis USGS GNIS Datapoints
pop USGS GNIS Datapoints w/population
map APRSdos Maps
map WinAPRS/MacAPRS/X-APRS Maps
Support for these additional map types has been compiled in:
geo Image Map (ImageMagick/GraphicsMagick library, many formats allowed)
geo URL (Internet maps via libcurl library)
geo URL (OpenStreetMaps via libcurl library
Copyright OpenStreetMap and contributors, CC-BY-SA)
shp ESRI Shapefile Maps (Shapelib library)
tif USGS DRG Geotiff Topographic Maps (libgeotiff/libproj)
xpm X Pixmap Maps (XPM library)
—
Reply to this email directly, [view it on GitHub](#382?email_source=notifications&email_token=AAINH6PE27PU4NVETAXAHGD46HCIBA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRHA2DOMBQUZZGKYLTN5XKU43VMJZWG4TJMJSWJJLFOZSW45FMMZXW65DFOJPWG3DJMNVQ#discussioncomment-17184700), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAINH6N4TTGTMKGHZ5JNI7D46HCIBAVCNFSM6AAAAACZLEFZ42VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMJYGQ3TAMA).
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for [iOS](https://github.com/notifications/mobile/ios/AAINH6JTA53WSJFSNR5YPZT46HCIBA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRHA2DOMBQUZZGKYLTN5XKU43VMJZWG4TJMJSWJJLFOZSW45FKMZXW65DFOJPWS33T) and [Android](https://github.com/notifications/mobile/android/AAINH6JZD5ZKQP7SJAE7UA346HCIBA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZRHA2DOMBQUZZGKYLTN5XKU43VMJZWG4TJMJSWJJLFOZSW45FOMZXW65DFOJPWC3TEOJXWSZA). Download it today!
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
|
Actually, since the error messages you were seeing are sent to stderr and those debug outputs are sent to stdout, you might still be seeing error messages but they didn't get saved in the output you captured (you'd have to do [edit: on review, most debug output is sent to stderr, not stdout, so if you did capture stderr properly, I'm now at a total loss to explain what you're seeing, as nothing here is making any sense --- at least when you were getting errors about the map_index.sys file format it was pointing to a possible read problem, now NOTHING is helping pin this down] |
|
The only weird stuff I found has been second "config" folder inside main config: marco@linux-turion64:~> ls -l .xastir/config/config/ Then I deleted it: marco@linux-turion64:~> rm -rf .xastir/config/config marco@linux-turion64:~> ls -l .xastir/config Behavior not changes: after selecting a map and saving the configuration, no maps appear at startup and I need to redo all again. |
|
That is weird and I have no idea how it could have happened. Have you not yet tried my suggestion of temporarily moving the entire .xastir directory out of the way and letting Xastir recreate it? I understand it's a pain in the butt to have to recreate all your customizations, but right now we're flying completely blind and there is clearly something wrong with how Xastir is dealing with the files in that directory. Moving .xastir out of the way (not just one or two files inside it) and letting Xastir start from scratch is really what we need to see next. And when you do it, please post everything that Xastir outputs, not just what you think might be relevant. Since I can't reproduce what you're seeing, there is no way to diagnose this without all of these things being tried. |
|
I could try it tomorrow and let you know the outcome. |
|
Hello Tom, I tried by moving .xastir folder away but the outcome is exactly the same for me. I'm going to attach the console outputs I grabbed. In any case, if this issue isn't resolvable don't worry, I will rescan the maps and select one at every boot. Regards, Marco |
|
Could you try running the following commands: |
|
Marco already did all that and posted the results: #382 (reply in thread) |
|
Sorry, missed it while scrolling through the history. |
|
The following is mostly for @tvrusso. I threw GitHub CoPilot at this to see if it provided any useful insights. Next weekend is the MS 150 so I'll be too busy to really look at what it gave me until after that. I'll post it in here in case Tom wants to take a look. It very well could be total hogwash. (I am, in fact, dubious of its theory.) Feel free to not spend time looking at it. :) Root Cause Analysis: Discussion #382 (Maps Not Loading)What the error messages tell usThe key symptom is: The filename The filename shown in the error includes Why
|
| # | Cause | Evidence |
|---|---|---|
| 1 | %Nc in sscanf requires exactly N chars on this system, causing the 11-field format to fail for any filename < 2000 chars |
Error filename shows 8-field fallback was used; maintainer can't reproduce (different glibc behavior) |
| 2 | Directory entries always have usgs_drg=2, which maps to auto_maps=2 in the 8-field fallback — a latent design issue since 2005 |
Confirmed at maps.c |
| 3 | doing_migration is triggered by any parse failure, not just genuine old-format files, causing the corrupt-save cycle |
Confirmed by code flow in index_restore_from_file |
| 4 | Residual share vs share path mismatch causes the selected map path to never match the index | Confirmed by maintainer analysis of the user's cnf; the "correct" path never survives across restarts |
The most actionable fix for developers would be replacing %2000c with a reliable approach (e.g., %2000[^\n] or parsing the last field by scanning past the 10th comma), and ensuring doing_migration is only set for genuine old-format records (by checking the field count pattern rather than just processed < 11).
Based on everything in the discussion and code, this is a long-standing latent bug that only manifests on systems where sscanf %nc behavior is strict, or on fresh installs where the old/new path mismatch hasn't been manually resolved.
|
Actually, that's an entirely plausible explanation --- and one that matches my observation that somehow that first attempt is failing to find 11 fields (my debug statement suggested to Marco would have confirmed that if only 10 were read, but we never saw that output). Everything else in that analysis is something I'd already figured out (obviously it is falling back to the final "older" format and getting the last three integers and the filename as if it were that final string field). However, if it is indeed the case that this is a misuse of the %Nc field in scanf that relies on non-posix standard compliance, we need to fix that. There's a lot of abuse going on here. We should also be removing all of that 21-23 year old fallback stuff. If someone still has config files from 2005 or 2003 (when the two different "old" and "older" formats were valid), the answer is for them to remove their map index files and let Xastir generate fresh ones, not band-aid the old files. |
|
Actually, Marco's last post of Xastir output does in fact show that all of those lines were failing by reading only 10 fields, not 11, and therefore it absolutely confirms what Copilot is suggesting --- the final filename field is not properly being read because of the misuse of %Nc. The fallbacks are improperly concluding that if we didn't get 11 fields it must be the case that we have an old file and then start kludging to read the file as if it were an old version. This is Just Wrong. |
|
Issue report #383 opened. I'll try to get on this sometime this weekend. The right fix is to take everything from the final comma on the line to the end as the file name, and parse the other 10 fields from what remains. We also will remove the fallback code as working around ancient map indices should not be needed anymore and just complicates the function unnecessarily. |
|
I just created a pull request that should fix this issue. Once I merge it to master (which I will do after all the automated testing finishes), you should reset your git clone (discarding all the hacking we did on it) with: after which you'll be able to pull the changes with If Copilot's analysis is spot on (and I believe it is), then this PR should fix your map indexing problem. |
|
Dear Tom, your map.c correction and merging, has resolved the issue definetely! Congratulations and many thanks for your dedication and efforts! Best regards, Marco |
|
🎆 🍾 Hooray. Thank you for bringing this up. This problem would certainly have surfaced for more users as soon as other distros catch up with OpenSUSE. Thanks also to @godfreja for thinking to ask Copilot about it, since I can't use the features he's paying for. |
|
FWIW, I asked copilot to review my PR with the following prompt: and it responded: Verification of PR #385 FixBased on my analysis of PR #385, the discussion in #382, and the issue report in #383, here's my assessment: ✅ Does the PR definitively resolve the user's issue?Yes. The fix directly addresses the root cause identified in the discussion. The Problem: On strict POSIX-compliant systems (like OpenSUSE), the The Solution: The PR refactors the parsing logic to:
✅ Does it address the other issues identified in the Copilot chat?Yes. The previous Copilot analysis (from discussion #382) identified:
|
I just created a pull request that should fix this issue. Once I merge it to master (which I will do after all the automated testing finishes), you should reset your git clone (discarding all the hacking we did on it) with:
after which you'll be able to pull the changes with
git pulland rebuild.If Copilot's analysis is spot on (and I believe it is), then this PR should fix your map indexing problem.