Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #29645 > unrolled thread

bug shows up depending on whether Java console is there or not.

Back to article view | Back to comp.lang.java.programmer

Contents

  bug shows up depending on whether Java console is there or not. Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-12 17:53 +0000
    Re: bug shows up depending on whether Java console is there or not. Marcel Mueller <news.5.maazl@spamgourmet.org> - 2014-08-12 22:41 +0200
      Re: bug shows up depending on whether Java console is there or not. Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-15 01:22 +0000
        Re: bug shows up depending on whether Java console is there or not. Marcel Mueller <news.5.maazl@spamgourmet.org> - 2014-08-15 11:07 +0200

#29645 — bug shows up depending on whether Java console is there or not.

(This is about an entirely different project)

This is a WebStart-App, that still requires Java 1.6 on client
PC's to avoid the certification requirements that come with 1.7.
(The server is running in "their" intranet with clients not even 
allowed to the external internet, so the security "features" of
1.7 are as useful to "them" as a hole in the head.)

The app includes some xml-parsing stuff with un-/marshalling
xml-documents. This happens inside a try-catch(JAXBException),
and the exception wasn't ever really thrown, up to including
1.6.0_u45.

Now, "they" apparently have a special licence from Oracle, so "they"
also get access to the later patchlevels of 1.6, and so "they"
recently switched to 1.6.0_u51.

Now comes the strange part:  with 1.6.0_u51, that code block throws
an JAXBException, but only if the java console is hidden.  As soon
as the console is activated, code runs through perfectly normal (as
it did up to 1.6.0_u45 regardless of console).

Is this "proof" that something is wrong with _u51, or could anyone
think of a programming error that would show up only with a specific
version and depend on console visibility and cause a JAXBException
to be thrown? On top of that, the getLocalizedMessage() method on the
thrown exception returns null, and thus we don't really get much
information about the problem itself.

PS: there are also newer 1.6 updates than 51, but the others seem to
  have included some of the 1.7 "features", so cannot be used, either.

[toc] | [next] | [standalone]

#29648

On 12.08.14 19.53, Andreas Leitgeb wrote:
> Now comes the strange part:  with 1.6.0_u51, that code block throws
> an JAXBException, but only if the java console is hidden.  As soon
> as the console is activated, code runs through perfectly normal (as
> it did up to 1.6.0_u45 regardless of console).
>
> Is this "proof" that something is wrong with _u51, or could anyone
> think of a programming error that would show up only with a specific
> version and depend on console visibility and cause a JAXBException
> to be thrown?

Almost anything could happen in case of a race condition.
Console access could serialize things that otherwise run in parallel.
Of course, I'm just guessing.

> On top of that, the getLocalizedMessage() method on the
> thrown exception returns null, and thus we don't really get much
> information about the problem itself.

What about the call stack? Try to find the corresponding throw in the 
Java source.


Marcel

[toc] | [prev] | [next] | [standalone]

#29670

Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
> On 12.08.14 19.53, Andreas Leitgeb wrote:
>> Now comes the strange part:  with 1.6.0_u51, that code block throws
>> an JAXBException, but only if the java console is hidden.  As soon
>> as the console is activated, code runs through perfectly normal (as
>> it did up to 1.6.0_u45 regardless of console).
>>
>> Is this "proof" that something is wrong with _u51, or could anyone
>> think of a programming error that would show up only with a specific
>> version and depend on console visibility and cause a JAXBException
>> to be thrown?
>
> Almost anything could happen in case of a race condition.
> Console access could serialize things that otherwise run in parallel.
> Of course, I'm just guessing.

Thanks for the guess, but that likely isn't the case here.

The code within the try-block doesn't really attempt to write to
the console. All logging activities are governed by a debugging flag,
and even when that flag is false, the presence or absence of console
still made a reliably *reproducible* difference.

I still keep it in backhead, though.

>> On top of that, the getLocalizedMessage() method on the
>> thrown exception returns null, and thus we don't really get much
>> information about the problem itself.
>
> What about the call stack? Try to find the corresponding throw in the 
> Java source.

That will be subject to check in the next days. 
My hopes are not very high (based on the null from getLocalizedMessage())
to find any other sensible information, but it is definitely worth a try.
(I need to add some code for that and have the user check again, as the
stack-trace of the JAXBException isn't currently visible to the user. So,
it'll take some time.)

Thanks!

[toc] | [prev] | [next] | [standalone]

#29672

On 15.08.14 03.22, Andreas Leitgeb wrote:
>> Almost anything could happen in case of a race condition.
>> Console access could serialize things that otherwise run in parallel.
>> Of course, I'm just guessing.
>
> Thanks for the guess, but that likely isn't the case here.
>
> The code within the try-block doesn't really attempt to write to
> the console. All logging activities are governed by a debugging flag,
> and even when that flag is false, the presence or absence of console
> still made a reliably *reproducible* difference.

Well, 'anything' also include this kind of symptoms. There is no need 
for a comprehensible relation to the cause. Maybe the console just 
changes the memory layout of the VM a bit.
I have seen really wired things. From a a silently aborting VM up to 
throwing the last caught (!) exception again at an arbitrary location.
Broken JNI code can raise similar Problems, as well as a broken JVM, of 
course.

>> What about the call stack? Try to find the corresponding throw in the
>> Java source.
>
> That will be subject to check in the next days.
> My hopes are not very high (based on the null from getLocalizedMessage())
> to find any other sensible information, but it is definitely worth a try.

AFAIK in Java the stack trace is captured by the Throwable constructor. 
It should be almost impossible to leave this field empty. But the stack 
trace may not match the location where the exception was thrown. This 
could add some confusion.

> (I need to add some code for that and have the user check again, as the
> stack-trace of the JAXBException isn't currently visible to the user. So,
> it'll take some time.)

It is always a good advice to include the stack trace when an exception 
is converted to a string. I wrote some helper for this purpose 
(ExceptionFormatter) since Java does not provide such a conversion. The 
message itself is often meaningless without a context.


Marcel

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web