This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 25185 - java parsing freezes ide
Summary: java parsing freezes ide
Status: CLOSED WORKSFORME
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P3 blocker (vote)
Assignee: issues@java
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-06-26 14:37 UTC by Jan Pokorsky
Modified: 2007-09-26 09:14 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
stack trace (17.92 KB, text/plain)
2002-06-26 14:39 UTC, Jan Pokorsky
Details
Sure, here is the thread dump (10.04 KB, text/plain)
2002-06-26 15:05 UTC, Jan Pokorsky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Pokorsky 2002-06-26 14:37:22 UTC
[jdk1.3.1_01, NetBeans IDE 3.4 Beta 2 (Build 200206201555)]

I'm not able to reproduce it reliably but from time to time it occurs. See attached stack trace.
Comment 1 Jan Pokorsky 2002-06-26 14:39:48 UTC
Created attachment 6433 [details]
stack trace
Comment 2 Svata Dedic 2002-06-26 14:56:12 UTC
Can you attach a thread dump, please ? The attachment is the ide
logfile -- interesting errors from the RequestProcessor (Petr, what
does that ISE mean ?), but no deadlock clue at all.
Comment 3 Jan Pokorsky 2002-06-26 15:05:24 UTC
Created attachment 6434 [details]
Sure, here is the thread dump
Comment 4 Petr Nejedly 2002-06-26 15:16:46 UTC
The ISE should not happen.
It is from java.util.Timer we use for delayed schedules.
It is thrown when Timer$TimerThread have its die boolean set.
The boolean is set to true only when:
a) If Timer is gc()ed (can't be - private static variable in RP)
b) Timer.cancel() is called (can't be - we don't call it)
c) TimerThread.run() finishes  - possible by exception in our
  TimerTask code, but there shouldn't be any exception and
  it would be logged, wouldn't it?
d) Someone killed the thread - the most possible case.
  In what circumstances have that happened (stopped compilation
  or something like that?)
Comment 5 Jan Pokorsky 2002-06-26 15:29:28 UTC
I'm not sure about circumstances but definitely not stopping 
a compilation. Maybe umounting a filesystem with opened files in 
editor or just closing these files. I'm really not certain about an 
action before the freeze.
Comment 6 Svata Dedic 2002-06-26 17:21:28 UTC
I am confused; there's no java parsing thread in the thread dump at
all ? That's interesting. I am positive that I only create the
RequestProcessor and never call stop() on it. Particular tasks posted
into the RP may be cancel()ed, but the RP itself is never stop()ed.
Petre, is there any reason (e.g. unhandled exception, ...) why the
RequestProcessor could terminate its thread ?
Comment 7 Petr Nejedly 2002-06-28 08:08:22 UTC
It has nothing to do with RP.stop nor Task.cancel()

The only possible thing that comes to my mind is somebody calling
Thread.stop on the timer thread. Maybe there is a problem
with initialization of RP from inside internal execution but
I can't believe RP can be initialized that late.

Yes, it can also be possible if exception occurs in the TimerTask
but look at the task I'm posting there from the RP's schedule...
I'll provide a logging patch on monday to test which of the cases have
occured if Jan will be able to reproduce it.
Comment 8 Tomas Hurka 2002-07-03 14:20:41 UTC
Unfortunately thread dump does not provide enough information to
locate and fix the problem.  Closing as works-for-me. Please provide
more info how to reproduce it.
Comment 9 Quality Engineering 2003-07-01 13:26:04 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.
Comment 10 Quality Engineering 2003-07-01 13:26:52 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.