weird: file missing when # of files > 10?
Hi list, I wrote about this before: my first map in the mapset, 63240001.img, is missing. I tracked this down to revision r1363 (which is a merge from the mapset branch) and today even further tracked it down to revision 1323 within the (deleted) mapset branch. However, I can't find any clues in r1323 as to what causes this. Further experiments showed even weirder results: as I compile my maps from a template.args file, it showed that having 63240001-63240009 in there would give me the correct map; having a 10th file in there made the first one missing. (Currently, while compiling the Netherlands, my template.args file has 14 entries. Any number above 9 makes the first one disappear). And indeed, when I duplicated the first file like so: mapname: 99999999 input-file: 63240001.osm.gz mapname: 63240001 input-file: 63240001.osm.gz mapname: 63240002 [...] ... the map would be correct (with the void 99999999 probably missing, and 63240001 included). Now I'm stumped. Would anyone know what's going on here? I thought of a race condition and removed the --max-jobs option, but that makes no difference. Best regards, Valentijn
Hi Valentijn,
Now I'm stumped. Would anyone know what's going on here? I thought of a race condition and removed the --max-jobs option, but that makes no difference.
I think you're right. It's a race between the stuff in CommandArgsReader that updates mapname and the map making code in Main, etc. I believe the fundamental problem is that the value of the mapname option gets read in the work thread which is asynchronous to the command args processing stuff that is updating the value of mapname (and other stuff probably). This will happen even if when only a single thread is in use (it's still asynchronous). Nasty, I will work on a fix - stay tuned. Cheers, Mark
Hi Valentijn,
Having looked at the code more, I realise that my initial thoughts were not right so I am back to the "stumped" state (i.e. I don't know what the problem is). Please tell me, what Java runtime/compiler are you using? Does the behaviour change if you use a different runtime? Cheers, Mark
Mark Burton schreef:
Having looked at the code more, I realise that my initial thoughts were not right so I am back to the "stumped" state (i.e. I don't know what the problem is).
Would it help you if I sent you the patch from the mapset branch that changes this behaviour? (Would save you from resurrecting a deleted branch).
Please tell me, what Java runtime/compiler are you using? Does the behaviour change if you use a different runtime?
AFAIK I'm running the Sun stuff - on an Ubuntu 8.04 installation. stout~$ javac -version javac 1.6.0_06 stout~$ java -version java version "1.6.0_06" Java(TM) SE Runtime Environment (build 1.6.0_06-b02) Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode) (Is that the info you need?) Regarding the different runtime - which one do you suggest? If you want me to put up a testing environment where you can log into remotely, I think I can manage this. Could send the password over the list, too ;-) No, seriously: I've just got a new internet connection here which is not installed yet, so hooking up a PC for the weekend would be no problem. If that's what would help, of course. Best regards, Valentijn
Would it help you if I sent you the patch from the mapset branch that changes this behaviour? (Would save you from resurrecting a deleted branch).
No thanks, I have all of the branches.
Please tell me, what Java runtime/compiler are you using? Does the behaviour change if you use a different runtime?
AFAIK I'm running the Sun stuff - on an Ubuntu 8.04 installation.
stout~$ javac -version javac 1.6.0_06 stout~$ java -version java version "1.6.0_06" Java(TM) SE Runtime Environment (build 1.6.0_06-b02) Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode)
(Is that the info you need?)
Yes, that's good enough. I was wondering if you were using something "exotic". But no.
Regarding the different runtime - which one do you suggest?
Actually, I'm using Ubuntu 8.04 and I get: java version "1.6.0_16" Java(TM) SE Runtime Environment (build 1.6.0_16-b01) Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode) Do you have "recommended updates" enabled in synaptic (or whatever package manager you are using). Let me think about this some more. Cheers, Mark
Mark Burton schreef:
Yes, that's good enough. I was wondering if you were using something "exotic". But no.
Good to hear from someone who agrees Ubuntu is not exotic :)
Actually, I'm using Ubuntu 8.04 and I get: java version "1.6.0_16"
After adding hardy-proposed to my sources.list: java -version java version "1.6.0_17" And... it fixes the problem. I ran a full build and it seems to be OK. Now I'm still stumped though - I think now Sun (Oracle?) is the only one who can fix that? ;) Thanks for your help. Best regards, Valentijn p.s. If you really, really want to know what happened, then just downgrade your Java version - something like sudo apt-get install sun-java6-{jre,bin,jdk}=6-06-0ubuntu1 should do.
And... it fixes the problem. I ran a full build and it seems to be OK.
Glad to hear it.
Now I'm still stumped though - I think now Sun (Oracle?) is the only one who can fix that? ;)
It's a weird problem, if I had all the time in the world I would have a trawl through the release notes and see if they have fixed any bugs related to file descriptors or similar.
Thanks for your help.
You're welcome.
Best regards,
Valentijn
p.s. If you really, really want to know what happened, then just downgrade your Java version - something like sudo apt-get install sun-java6-{jre,bin,jdk}=6-06-0ubuntu1 should do.
Err, I can live without that knowledge. Cheers, Mark
participants (2)
-
Mark Burton -
Valentijn Sessink