JFS - Trap 0003 - anyone?

[Dariusz Piatkowski]

Folks!

I figured I would inquire here first before logging a ticket for the AN folks on this JFS issue.

So the other day I had a weird situation: my nightly RSYNC job LOG needed to be "rotated" having grown to some 32M in size over the past couple of years. I decided to manually split it up into calendar year LOGs. I most likely had the file open in my editor while at the same time attempted to execute a CLI copy of that big file.

BAM!!!

JFS died with TRAP 0003...meltdown!

Following a power re-boot JFS did a check disk and uber quickly flashed some messages up on the screen about lost directories. The chkdsk forced an automated re-boot and a 2nd chkdsk run. At the end of what felt like the longest 5 mins ever I got back to my MAINT partition to discover that my 'lost+found' directory now had some 17k files. Clearly chkdsk found some directory problems and moved a boat-load of files into the 'lost+found' directory. Yikes!

Anywyas, I was aware that this is probably the worst JFS situation when directories are mangled. Now luckily for me I had a nightly backup (RSYNC...LOL), so I was able to recover just fine. The mangled directories turned out to be my Firefox and Thunderbird cache, thus the massive listing of files.

Now that I'm up and running again and spending a little time researching this I discovered the following description of a TRAP 0003:

TRAP 0003 - BREAKPOINT. This is a special instruction (INT 3) used in "debugging" software, which was left in the code either accidentally or by design. Contact software support.

Further on, the following is also available:

[G:\]help 1933

SYS1933: A program caused a breakpoint error.  The program was ended.

***

EXPLANATION: A program started an INT 3 instruction when it was not
being run by a debugger.

ACTION: Correct the program and retry the command.

I found this extremely interesting given that in this latest version of JFS AN announced a successful quashing of a JFS bug when operations on a file LARGER than the JFS CACHE would potentially trap.

In my case I am running a large 1G cache, so I do not think this to be the issue...however as I experiment with various MIN and MAX buffer settings I may have potentially ran into a problem there. Hard to tell and NO I have not tried to replicate this issue!!! ha....

Take a look at the attached TRAP screen...what do you guys make of it?

Thanks!

[Andi B.]

Recently I also had a JFS 0003 trap while I prepared a bootable ArcaOS USB stick.

I also read a while ago an explanation for one sort of JFS 0003 trap. What I remember is it had to do with removable devices where sometimes JFS find things on a volume which clearly do not match what it expects. Caused by the drive letter is now used by another volume. Hence JFS gives up for safety reasons. At least this is what I remember.

Did you search in the bugtracker for this? trap 003 or CS:IP or the location value?

[Dave Yeo]

I get those every few months, usually when copying a lot of stuff to removable devices IIRC. I've asked about them on the testers list but didn't really get a response.
Being a trap 3, a programmer likely put it there on purpose as it is better to trap then to write crap to a device.
I also see breakpoints hit in Mozilla code, which seems to happen when the memory gets inconsistent or not available. Same with the Simplebrowser where YouTube gave me a sigtrap until I marked the FFmpeg libs to load high. Of course a breakpoint in a program just crashes the program while in a device driver, it takes down the whole system.

[David McKenna]

 I also see these Trap0003 in JFS every once in a while (maybe 3 times a year?). Always after chkdsk runs, some cache files for SeaMonkey are either restored or not. Always thought it was a SeaMonkey problem, but maybe not?

Regards,

[Dave Yeo]

Probably not a SeaMonkey problem. The files were open when the trp happened so in an inconsistent state.
Personally, I've moved my SeaMonkey cache to my HPFS Ram drive. Preferences, Advanced, Cache

[David McKenna]

 Thanks, Dave - great idea about putting the cache on the RAM drive, I'll definitely try that.

Regards,

[Dariusz Piatkowski]

OK, thanks for the feedback you guys.

I'll hold off on getting that ticket logged. Instead, I changed my JFS cache settings to those that have proved to provide me the best performance and am currently running with these.

I suspect that the issue I had ran into was probably not caused by the BUFFER settings, however not having a spare setup to replicate this on I'm just going to try to "stay away" from the combo (settings and actions) that caused me that TRAP.

[Roderick Klein]

Folks!

I figured I would inquire here first before logging a ticket for the AN folks on this JFS issue.

So the other day I had a weird situation: my nightly RSYNC job LOG needed to be "rotated" having grown to some 32M in size over the past couple of years. I decided to manually split it up into calendar year LOGs. I most likely had the file open in my editor while at the same time attempted to execute a CLI copy of that big file.

BAM!!!

JFS died with TRAP 0003...meltdown!

Following a power re-boot JFS did a check disk and uber quickly flashed some messages up on the screen about lost directories. The chkdsk forced an automated re-boot and a 2nd chkdsk run. At the end of what felt like the longest 5 mins ever I got back to my MAINT partition to discover that my 'lost+found' directory now had some 17k files. Clearly chkdsk found some directory problems and moved a boat-load of files into the 'lost+found' directory. Yikes!

Anywyas, I was aware that this is probably the worst JFS situation when directories are mangled. Now luckily for me I had a nightly backup (RSYNC...LOL), so I was able to recover just fine. The mangled directories turned out to be my Firefox and Thunderbird cache, thus the massive listing of files.

Now that I'm up and running again and spending a little time researching this I discovered the following description of a TRAP 0003:

TRAP 0003 - BREAKPOINT. This is a special instruction (INT 3) used in "debugging" software, which was left in the code either accidentally or by design. Contact software support.

Further on, the following is also available:

[G:\]help 1933

SYS1933: A program caused a breakpoint error.  The program was ended.

***

EXPLANATION: A program started an INT 3 instruction when it was not
being run by a debugger.

ACTION: Correct the program and retry the command.

I found this extremely interesting given that in this latest version of JFS AN announced a successful quashing of a JFS bug when operations on a file LARGER than the JFS CACHE would potentially trap.

In my case I am running a large 1G cache, so I do not think this to be the issue...however as I experiment with various MIN and MAX buffer settings I may have potentially ran into a problem there. Hard to tell and NO I have not tried to replicate this issue!!! ha....

Take a look at the attached TRAP screen...what do you guys make of it?

Thanks!

Is this under ArcaOS ? I ask this as I am not familiar with older OS/2 versions. But if you are running ArcaOS are you also dealing
the latest ACPI, JFS and OS2KRNL from Arca Noae ? They contain different fixes that can resolve a TRAP 3.
But I am not certain.

ROderick

[Dariusz Piatkowski]

Hi Roderick,

Is this under ArcaOS ? I ask this as I am not familiar with older OS/2 versions. But if you are running ArcaOS are you also dealing the latest ACPI, JFS and OS2KRNL from Arca Noae ?

No, this is not AOS. Warp 4.52 actually, SMP of course using the AN drivers, that includes the latest kernel and JFS.

I rarely (if ever anymore) put anything in as a ticket with AN because their official policy is to support only the AOS environment. It may have been somewhat different when the 'OS/2 Drivers' subscription was initially available (not sure if it is anylong actually or not).

[Dave Yeo]

The problem is that you are using the latest kernel on Warp v4.52. IBM has only licensed it for ArcaOS so Arca Noae isn't going to support it, at that they basically can't support it.

[Dariusz Piatkowski]

Dave,

The problem is that you are using the latest kernel on Warp v4.52. IBM has only licensed it for ArcaOS so Arca Noae isn't going to support it, at that they basically can't support it.

That I understand, however my less-than-conducive experience stems from working through some issues I had BEFORE the latest kernel was even being talked about and subsequently released...bottom line: DA's take on my multiple reported issues simply was "unless you're running one of our approved combinations I can't help you"...soo...I gave up!

Besides, you know this very well, take a look at the latest USB driver test request on our Testers List, see that glaring:

As always, please review and follow the Arca Noae Test Team Policy which is available here:  https://www.arcanoae.com/wiki/test-team-policy/

...which I have no access to, so maybe you can tell me what's on there?

Meanwhile I'm guessing that there are way many more hardware combinations out there that the USB driver test effort would benefit from, folks who are NOT currently running AOS, and yet we leave that opportunity completely un-tapped.

Anyways, politics, whatever...following my multiple attempts at providing testing/debugging value I gave up and decided to focus exclusively on stuff that somewhat still remains non-AOS core, such as the Samba clients, general apps (Lucide, etc.).