I'll read through everything properly a little later and get back to
you if I have any ideas.

In the mean time, don't forget that all the tutorial & demo apps are
in SVN too, and do not have to be run as applets.
http://svn.apache.org/repos/asf/pivot/trunk/tutorials/
http://svn.apache.org/repos/asf/pivot/trunk/demos/

Both of these already have main() methods that will launch them as desktop apps.
http://svn.apache.org/repos/asf/pivot/trunk/tutorials/src/org/apache/pivot/tutorials/explorer/ComponentExplorer.java
http://svn.apache.org/repos/asf/pivot/trunk/tutorials/src/org/apache/pivot/tutorials/KitchenSink.java

There are also lots of 'test' apps which demonstrate most of the
features in Pivot, so you should be able to find ones for a specific
area of functionality (such as popup context menus) and run those to
try to rule out your code being the problem.
http://svn.apache.org/repos/asf/pivot/trunk/tests/

On 6 August 2011 11:28, Roger and Beth Whitcomb
<[email protected]> 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<[email protected]>
>>  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
>>>
>>> [email protected]
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>
>

Reply via email to