When I ran it on Windows with decompiling set to all packages (as I
assumed you did), it hung while decompiling xercesImpl.jar (I could tell
this from the logs). Looking on disk, there was a 0 byte file
CoreDocumentImpl.java that appeared to be the last thing it was working on.
So, I ran both Procyon 0.5.25 and 0.5.26 on it on Fedora, and both have
hung in exactly the same place. This is obviously not a platform
specific bug. I'll try to file this upstream with the procyon maintainer.
On 10/15/2014 10:06 AM, Ondrej Zizka wrote:
I am getting to it tomorrow (going to a JBUG with Mark Little
today).
I have a SSD on linux and HDD on Windows. Not sure how I/O heavy
decompilation is, I assume not much. I don't have/know any free I/O
analysis tools on Windows. But I'll set up breakpoints and check
what's going on.
Ondra
On 14.10.2014 20:53, Jess Sightler wrote:
> We also need to know whether it is actually getting stuck (and taking
> >1 minute/class). Do we maintain any stats like that at the moment?
>
> On 10/14/2014 02:52 PM, Lincoln Baxter, III wrote:
>> In theory, this is a good idea, we probably do want to limit the
>> amount of time spent on each class.
>>
>> However, simply running decompilation in a separate thread will
>> likely not allow us to interrupt the thread. We'll need to figure
>> out where Procyon is running, and if it actually responds to
>> Thread.interrupt() (I'm betting it doesn't.) (And how to make sure
>> that it does, which will likely take some extension or modification
>> of Procyon itself.)
>>
>> This is definitely something to look in to over the next few
>> weeks/months as we harden this first version of the tool.
>>
>> On Tue, Oct 14, 2014 at 1:42 PM, Brad Davis <bdavis(a)redhat.com
>> <mailto:bdavis@redhat.com>> wrote:
>>
>> I think we could maybe create the decompiler as a runnable, and
>> interrupt the thread with a timeout if the decompiler takes more
>> than a minute for a class, which should be plenty of time. We
>> should log this, though, to make sure they are aware that one of
>> the classes did not successfully decompile.
>>
>> Brad Davis
>> Senior Manager, Red Hat Consulting
>> Email: bdavis(a)redhat.com <mailto:bdavis@redhat.com> | c:
>> 980.226.7865 <tel:980.226.7865> |
http://www.redhat.com
>>
>>
>> ----- Original Message -----
>> From: "Ondrej Zizka" <ozizka(a)redhat.com
<mailto:ozizka@redhat.com>>
>> To: "Windup-dev List" <windup-dev(a)lists.jboss.org
>> <mailto:windup-dev@lists.jboss.org>>
>> Sent: Tuesday, October 14, 2014 11:55:17 AM
>> Subject: [windup-dev] Windows Issues
>>
>> Hi,
>>
>> I've tried on Windows 7 64bit, Oracle JDK 1.7.0_67.
>>
>> The tests fail with WINDUP-335 and WINDUP-332 .
>> The run against Tim's EAR get stuck on Decompilation for about 8
>> hours, seems it's in an endless loop. WINDUP-337
>>
>>
>> Is Windows a priority? Do we have estimation on what portion of
>> users will run on Windows?
>>
>> Ondra
>>
>>
>>
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev(a)lists.jboss.org <mailto:windup-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/windup-dev
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev(a)lists.jboss.org <mailto:windup-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/windup-dev
>>
>>
>>
>>
>> --
>> Lincoln Baxter, III
>>
http://ocpsoft.org
>> "Simpler is better."
>>
>>
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/windup-dev
_______________________________________________
windup-dev mailing list
windup-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev