Bug with file unit numbers 2121 and 1600

[michael_m2]

Hello:

I think I discovered an abscure bug and was wondering if you at Intel are aware of it and if it has been fixed. It is with version 10.0.025. (When I switch back to 9.1everything worksfine.)

Basically, when I open a file with unit 2121 and subsequently open a file with unit 1600, the second file opening causes the first one to be corrupted (i.e.,unit number2121 is no longer associated with any specific file).

I have attached a simple program that demonstrates this bug. I have tried many other combinations of unit numbers (including switching the order in which the 2 files are opened) and none of them replicates this bug. It only happens (from what I could tell) when file 2121 is opened, and the file 1600 is opened.

I guess I should report this to Premier Support, but was first wondering if anybody else has stumbled across this, or if anyone knows more information about it.

Thanks.
Michael

[Steven_L_Intel1]

I've never seen this issue before - it is strange. Please do report it.

[michael_m2]

OK, thanks.

I have submitted it -- the issue number is 460077.

Thanks.
Michael

[Steven_L_Intel1]

Thanks. I have to ask - how did you discover this? It seems to require just the right combination of unit numbers.

[michael_m2]

Just pure luck! I was actually assiting a co-worker debug his program. He couldn't figure out why he kept getting a fort.2121 file with the contents of his output, while the "real" file (i.e., the one with the file name he was intending to use) was created but as an empty file.

After a while of experimenting and tinkering, I was able to narrow it down to this issue. It's quite puzzling -- like you said, I can't find any other combination of unit numbers where this happens! I'd be curious, once this issue is starightened out, if you could summarize what's going on internally in the compiler that wascausinging this strangeness.

Michael

[Steven_L_Intel1]

It's actually in the run-time library, but the distinction may not be relevant to you (it is to me). What I found was that when you opened unit 1600, unit 2121 got closed. Exactly WHY this happens, I do not yet know, but I will find out...

[michael_m2]

Another clue: I found more unit number pairs where this strange behavior occurs. It looks like it happens any time the first unit number is exactly 521 bigger than the second unit number, and the second unit number is at least 100.

Michael

[Steven_L_Intel1]

Thanks. That value 521 is significant. The library uses a hash to map a unit number to the pointer to the internal data structure and the hash table size is 521. In the problem cases, the two units map to the same hash table entry. There is "collision detect" code that should deal with this but apparently it is not working quite right. We'll fix it.