Boot-time exceptions are killing the input drivers!!

I will investigate this.

If it helps, I hacked together a log4j appender to output log messages using Unsafe.debug(String). It appears that the exception stacktraces are NOT coming from log4j. I guess that means they are coming from some direct call to printStackTrace.

Here we go. I've captured the stack traces via Unsafe.debugStackTrace(); see this comment's attached file. It looks like more security exceptions.

In addition to fixing the direct cause of these exceptions, I suggest that we change what ever is generating these stacktraces to either call Unsafe.debugStackTrace() or use log4j. This will make it easier to investigate them. I think we should do this for ALL calls to printStackTrace in the JNode parts of the 'core' codebase.

A note on that: I think when levente integrates new stuff from openjdk he localy switches off the access control in JNode. I thought this was an option in configure, but it is not. So despite this bug, perhaps we should make this a configure option?
Levente, can you tell us where/how you switch off security?

You can easilly turn off the security in jnode.properties with: jnode.security.enabled=false

I fixed those exceptions during startup.

Steve, your debug output was of great help, but the sugested solution to use either Unsafe or log4j might not work because it may imply changing arbitrarily the openjdk classes. Instead we better have a method in place that we can use on those rare occasions when we have exceptions during startup that we cannot easily see.
Actually you have the method already, so can you document it somewhere?

I agree. When I wrote "... in the JNode parts of the 'core' codebase" I was trying to say that that my suggestion excludes the OpenJDK, Classpath and other code that we import from elsewhere. But I expect we would find that the OpenJDK core libraries are (almost) printStackTrace free ...

I was also thinking that we could use custom checkstyle rules to discourage the checking in of printStackTrace calls in org.jnode core and driver clases.

BTW, the "technique" I used to capture the stacktrace was to add a hacky call of the Unsafe.debugStackTrace method to the appropriate Throwable.printStackTrace method and rebuild JNode. I'm not sure that we want to document ugly hacks like that, if that is what you were suggesting. IMO, it would be better to replace the printStackTrace calls with something that can eventually be controlled by build and/or boot options.

FWIW, it works for me, r4815 on KVM, built with openjdk.

Yes ... the fix for the critical security bug is in rev 4814 (I think). Anyway, I'm reassigning this issue to myself to address the printStackTrace issue.

I'm still thinking about the right solution bacause I'm not sure it's a good idea to make the very core of jnode (the code packed into the system plugins) depend on log4j. By this time there are only a few dependences on log4j if any. A non-intrusive, lightweight solution with no new external dependencies would be ideal.

How about using org.jnode.system.BootLog?

BootLog would need to be changed (depending on boot options) so that its output always goes to the kernel debug stream. Currently, the Log4jPlugin reconfigures BootLog so that output just goes to the JNode console. That would need to be changed as well.

We are basically interested in something that is sent to the boot console. So how about having an option like verbose_kdb which enabled will send everything to the serail port whatever is sent to the boot console. Since this is needed only occasionally and it can degrade performance I suggest that this features is not turned on by default. It could be turned on with a build option or with a kernel option for more flexibility. This solution doesn't need any change in the overal source code (except the console) so it looks quite unintrusive.