pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Bartlett <cbartlet...@gmail.com>
Subject Re: Any reports of...
Date Sat, 06 Aug 2011 06:18:22 GMT
Having read through it all this time, I can't really suggest anything
else other than the tedious (but seemingly necessary) methodical
behaviour comparisons across JVMs, OSs, custom/Pivot code etc.

Ideally before starting down that route you would already be able to
reliably reproduce the issue, but it sounds like there may be more
than one issue anyway.

If the problems seem to show up mainly on RHEL, then I'd say just
focus on running as much Pivot code from SVN as you can to see if you
can trigger the same sorts of issues as with your custom app.  It is
probably also worth testing the 2.0 and 1.5.2 jars too just to rule
out the specific Pivot version, and to try to find some pure AWT apps

I doubt that I have told you anything you didn't already know, so
hopefully someone else on the mailing list will have some bright


On 6 August 2011 11:28, Roger and Beth Whitcomb
<RogerandBeth@rbwhitcomb.com> wrote:
> Hi Chris,
> It is a DesktopApplication.  I'm having trouble running applets because of
> Java browser plugin installation issues, so I can't tell if
> ComponentExplorer or KitchenSink works or not.  I have a smaller Pivot
> desktop app that seems to run fine, but it doesn't have a lot of the
> interaction of our main app (no right-click menus, no tree view, etc.).  I
> can't (yet) run our application from a browser, so I can't tell if that
> would make a difference or not.
> It happens at irregular times, but often just when I right click on a tree
> view node, or at application startup time when I am loading components into
> the tree on the "main" thread.  It still happens even with all my own
> background threads disabled, so the only threads running are the ones
> launched by the JVM and the AWT-EventQueue-0 thread (or possibly Pivot Tasks
> doing resource loading).  I have had it run for 10 or fifteen minutes
> sometimes, but lately it crashes fairly soon into the application.  Usually
> when it crashes it also crashes the dump generator, so there is no reliable
> stack frame in the "hs_err_pidxxxx.log" file either.  "valgrind" reports no
> problems, "gdb" is unable to print a stack frame, and "strace" shows nothing
> unusual either.  Usually, but not always, what's reported is a SIGSEGV or
> SIGABRT that crashes the JVM and the crashing address is somewhere inside a
> monitor wait (like "pthread_cond_wait", or sometimes in "kill").
> The identical Java/Pivot code runs fine on all our other environments,
> although on Win32 there was a SEGV reported that was handled by an exception
> handler somewhere deep inside the JVM.  The only platform-specific code is
> inside JNI routines and the only code differences are in a mutex class
> (Windows uses "CriticalSection" and OSX/Linux use "pthread_mutex").  But, I
> put "printf" tracing around the mutex stuff on RHEL and it appeared to be
> working fine.  And usually the crash occurred within Java code (i.e.,
> nowhere near the JNI code layer).  And, as I said, I disabled my own
> background thread (which was my first thought) so that the only thread
> running with my application code was the AWT event thread, so there was no
> possibility of multiple threads in my own code interfering with each other.
> So, I'm left with a complete mystery, and the more so because the OSX code
> and the Linux code, from my end, are almost identical and OSX works
> flawlessly (and has done so both 32-bit and 64-bit).  I can't remember, now,
> whether I've been running Pivot .jars
> Oh, the original version of Java I was using was OpenJDK that was certified
> with RedHat (something like 1.6_16).  But, yesterday I tried installing the
> latest Oracle 1.6_26 version and it was essentially exactly the same result
> with either.  Although, I'm not sure I can't rule out installation issues,
> since my Linux knowledge is sketchy at best.  But, our system admin did the
> original OpenJDK installation, and I'm pretty sure he knows what he's doing.
> Sorry this is so long, but (as you can probably tell), this has been rather
> frustrating.  I'm kind of grasping at straws here, since I'm pretty sure the
> problem lies in my code, but I am at a loss to be able to figure out where.
>  HTH.  Thanks for any insights anyone might have.
> ~Roger Whitcomb
> On 8/5/11 7:49 PM, Chris Bartlett wrote:
>> Can you elaborate a little on the crashes, or if you think they are
>> limited to that particular version of RHES?
>> Does it matter how the app is launched?  (Applet/desktop app/web start)
>> Have you tried things like the KitchenSink or ComponentExplorer demos
>> (I assume you are taking about non-headless apps)?
>> On 6 August 2011 07:55, Roger L. Whitcomb<Roger.Whitcomb@ingres.com>
>>  wrote:
>>> … problems with Pivot on Red Hat Enterprise Linux Server release 5.7
>>> (Tikanga)??
>>> uname:Linux 2.6.18-274.el5 #1 SMP Fri Jul 8 17:36:59 EDT 2011 x86_64
>>> libc:glibc 2.5 NPTL 2.5
>>> rlimit: STACK 10240K, CORE 0k, NPROC 3072, NOFILE 1024, AS infinity
>>> I’m getting crashes all over the place in this environment whereas on
>>> Win32,
>>> Win64, OSX 64 everything is working fine.  Must be something I’ve done in
>>> my
>>> platform-specific code, but I just thought I’d check to see if anyone had
>>> seen problems in this environment.
>>> BTW, it happens either with OpenJDK or Oracle/Sun released JDK.
>>> Thanks.
>>> Roger Whitcomb
>>> Architect, Engineering
>>> Ingres Corporation
>>> roger.whitcomb@ingres.com
>>> PHONE +1 650.587.5596
>>> FAX +1 650.587.5550
>>> www.ingres.com
>>> This transmission is confidential and intended solely for the use of the
>>> recipient named above. It may contain confidential, proprietary, or
>>> legally
>>> privileged information. If you are not the intended recipient, you are
>>> hereby notified that any unauthorized review, use, disclosure or
>>> distribution is strictly prohibited. If you have received this
>>> transmission
>>> in error, please contact the sender by reply e-mail and delete the
>>> original
>>> transmission and all copies from your system.

View raw message