OS/2, eCS & ArcaOS - Technical > Storage
JFS TRAP000E during unzip on JFS partition (same unzip on fat32 is ok)
Remy:
--- Quote from: Andi B. on December 04, 2022, 07:17:25 pm ---
--- Quote from: Remy on December 04, 2022, 05:33:24 pm ---.....
It looks there is confusion.
It isn't me.
--- End quote ---
I didn't know there are more than one Remy using ArcaOS. This ticket I posted in the other threat is what I meant - https://mantis.arcanoae.com/view.php?id=1223. Out of curiosity this was a TRAP 000E too.
--- End quote ---
Oh ! I apology, yes, right it was me but a very old case from 2017 resolved in 2017 (older ArcaOs release)
Now and I'm under ArcaOS 5.0.7 (after check, I have rdmsr.sys - May be I put it back after 5.0.7 migration - I just added a Warning REM line into my config.sys about this driver)
I don't think this driver has something to do here due following test:
About the new issue, could it be possible I exceed authorized number of files or dirs on this partition ? or may be exceed possible JFS entries ?
(Deleted about 20 files and the copy could be done without trap !)
Lars:
It would be interesting if that Trap E always occurs at the very same location (the lowest 4 hex digits of EIP having the same value would be a good indication, I don't have access to ticket 1223).
The trap is due to an attempt to write data to a non-present page. Taking the value displayed for CR2, I would think a NULL pointer being accessed (with an offset of 0x38). It's difficult to say what would have caused that but a NULL pointer check should be added in JFS.IFS.
Since JFS.IFS dynamically allocates memory from an internal pool whenever that is necessary, maybe all memory was depleted and a NULL pointer returned. Since it seems to depend on file size, it may have something to do with allocating "inode" management data.
Remy:
--- Quote from: Lars on December 05, 2022, 01:20:01 pm ---It would be interesting if that Trap E always occurs at the very same location (the lowest 4 hex digits of EIP having the same value would be a good indication, I don't have access to ticket 1223).
The trap is due to an attempt to write data to a non-present page. Taking the value displayed for CR2, I would think a NULL pointer being accessed (with an offset of 0x38). It's difficult to say what would have caused that but a NULL pointer check should be added in JFS.IFS.
Since JFS.IFS dynamically allocates memory from an internal pool whenever that is necessary, maybe all memory was depleted and a NULL pointer returned. Since it seems to depend on file size, it may have something to do with allocating "inode" management data.
--- End quote ---
Ticket number for this issue:
https://mantis.arcanoae.com/view.php?id=3366
chkdsk of the partition run from ArcaOs boot DVD:
Dariusz Piatkowski:
Hi Remy!
I'm curious if by any chance you hit the same issue I did back in Jan of this year, see this thread => 'JFS - Trap 0003 - anyone?' (https://www.os2world.com/forum/index.php/topic,2962.0.html)
Specifically for me this was caused by the JFS cache size (and the MIN & MAX buffer parameters) and the size of the file I was working on. It was reproducible as well.
Remy:
--- Quote from: Dariusz Piatkowski on December 05, 2022, 02:51:44 pm ---Hi Remy!
I'm curious if by any chance you hit the same issue I did back in Jan of this year, see this thread => 'JFS - Trap 0003 - anyone?' (https://www.os2world.com/forum/index.php/topic,2962.0.html)
Specifically for me this was caused by the JFS cache size (and the MIN & MAX buffer parameters) and the size of the file I was working on. It was reproducible as well.
--- End quote ---
Same location.
Interesting, I use default AN size
What are you cache / buffer sizes ?
Of course, trap should not occur and warning messages should be issued several seconds before any other deeper issue followed by may be a kill of the process which could put the system into a trap situation... ::)
Regards
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version