And have you changed the maximum heap size setting in the startup script?
Perhaps the OS/2 launcher should set a higher default. If the JVM really runs
out of memory, there is not a lot the IDE can do about it, pending more
sophisticated memory-levels support from the JVM (once planned for JDK 1.2 but
cancelled).

I honestly think this is either:

1) A JVM bug (possible, but since Netbeans is the ONLY app that gives me 
this, it's doubtful)
2) A bug in Netbeans since no matter if I give it 150MB of ram or 50MB it 
gives me the OutOfMemory error in the same places just as often. 
Furthermore, the error comes and goes even without me restarting the IDE

Sounds like a bug to me..

assigning

I've reproduced this on WinNT 4.0, JDK 1.3 by Sun now. So we can now safely 
assume it's not platform or JDK-dependant. 
This is a Netbeans bug.

Version: 'Dev' -> 3.2

OK, let's look at it.
The stacktrace says nothing about the cause, so we could try to colaborate
on it to find the roots.
It (OOME) happened to me in the history, but on a special setup and not
regulary.
I'll try to reproduce it here, but I'd like to ask you if you could
let the MemoryView example running while you're working (it costs virtually
nothing, only takes space on the screen) and check if the memory
usage grows on some tasks.
There is a possibility of a memory leak in the Dialog code, whether in NetBeans
or in JDK, that could fit to your 'mount' and 'new' scheme. I'll try to
investigate it with HAT here and let you know more.

I've tried leaving MemoryView open as I run into this bug, clicking on 
garbage collector does reduce the memory usage quite a bit but it doesn't 
seems to have any effect on this specific error. Meaning that even when 
MemoryView says 20MB out of 30MB used it still gets OutOfMemory errors.

Hmm, seems strange. It brings more questions than answers...
The JVM can't signal OOME while still have something to
clean or where to grow. Unless we're trying to allocate the world somewhere.

Is the exception always similar or are the exceptions *very* different from each
other?
On which VM it happened when you had only 30MB of Heap me mory?
Does the exception occur when running on NT with the similar memory numbers?

I've only get OOME when I was running the IDE with -Xincgc -Xmx48m,
and only during massive redisplays (desktop switch), when the Swing
was trying to allocate off-screen buffer to paint to (~8MB on my huge screen).

I know, this doesn't make a lot of sense to me either which is why I 
thought it was JVM-specific at first, but it is not. I guess you would 
get OOME while having free ram if you tried allocating A LOT of ram all 
at once, and the JVM would fail it since not enough ram was available but 
it would not show up in MemoryView because none of the allocation had 
taken place.. That's one possibility I can think up of.. Like when you do 
"new String[2000000000000];" or something... but the bug might be 
something totally different..

I am using JDK 1.3 by IBM for OS/2 here and JDK 1.3 from Sun on the NT 
machine in the labs. I limit my JVM to 96MB ram here and to an unknown 
amount at school (I don't control those machines).

.... One issue you must be made aware of. I have noticed that 
totalMemory() under IBM's JDK 1.3 does not return the 'true' available 
memory; and I assume JDK 1.3 by Sun might do the same but I have not 
checked yet.. Say you have a 96MB heap and you have allocated 20MB so 
far, totalMemory() will return something like 25MB (very close to what 
you have already allocated).. when you try to allocate past that limit, 
it will grow with you; up to 30MB or so.. all the way up to the REAL 
limit which is 96MB at which point you will get OOME. I assume this is 
done to encourage more frequent garbage collection (since that takes 
place when 75% of totalMemory() has been allocated). 

This might account for the behavior you're getting if you're not aware of 
this behavior. But if you allocate using "new XXX();" blindly and let the 
JVM return OOME if one does occur then this shouldn't be a problem.

any update on this issue?

the totalMemory() behaviour is correct and usual. It says how much heap the JVM
actually allocated from the OS. The JVM keeps it lower to not take over all the
OS memory, when it is not acually needed. The condition for spawning gc() is
much more complicated than [75% of the allocated heap is used], it takes into
account several factors to e.g. limit the frequency of gc() - deals with dynamic
characteristics of the running program (say, it allocates heavily now, so it
will grow the heap instead of spawning gc()).

AFAIK, nobody checks freeMemory() before allocating, it is braindamaged and the
freeMemory method was never intended to be used this way.

I've asked if the stack traces of this exception are the same, similar or
different each case and didn't get response, so I'm reiterating the question.
Now I see there are two different stack traces attached ...

There is also possibility that the OOME on NT is unrelated to the OOME you're
getting on OS/2 or that the JDK/NetBeans instalation (said that you don't
control it) is screwed up.
Could you please try to run a little program which will allocate some objects
(e.g. 1M byte arrays) until it get OOME and run it both on OS/2 and in the lab?

1) Both stack traces (the first and last) came from OS/2 and they both 
resulted in the same error and so I assume they are both related

2) I have tried a testcase program on OS/2 whereby it allocates memory in 
small or even big chunks and it always gives me OutOfMemory correctly 
when I allocate all my memory. Then again, my testcase program did not 
involve any GUI; rather it just kept on allocating new String[100000]; 
and adding them to a Vector so they would not be deallocated.

3) Out of all Java programs I am using, Netbeans is the most complex but 
all-the-same it is the ONLY one that experiences this OutOfMemory error 
which is why I am more tempted to say it is Netbeans-specific.

4) I will test memory allocation in the lab if you wish, but it will take 
me a while (a week or so) because I'm quite busy this week.

5) Is there any more information I could provide you with that will help 
you track down this problem? Could you send me some modules with 
debuging-mode enabled or something that will output more information to 
help you?

Created attachment 834 [details]
Source-code used to reproduce bug in Debugging-mode

Ok, lets tackle this one step at a time.. I found steps to reproduce this 
error on demand. Lets tackle this first and see if the other stack traces 
were related or not; the resulting behavior seems to be the same no 
matter which stack trace I get.

I'm using Netbeans beta build 7 under JDK 1.3 for OS/2.

Ok, one way I found to easily reproduce this bug is to:

1) Open Newton.java (attached)
2) Set breakpoint at line 205
3) Press F5 to begin the JPDA debugger
4) The debugger will stop at the correct line
5) Scroll a few lines down to "A = findLU(A);" and press F4 to "RUN TO 
CURSOR"
6) Exception will be thrown:

Tue Mar 20 01:54:43 EST 2001java.lang.NullPointerException: null
Annotation: Exception occurred in Request Processor
org.openide.util.RequestProcessor$Holder(task 
org.netbeans.core.ModuleActions$1@e7adabc [-2625, 1])
        at 
org.openide.util.RequestProcessor$Holder.<init>(RequestProcessor.java:234
)
        at 
org.openide.util.RequestProcessor$Task.createHolder(RequestProcessor.java
:274)
        at 
org.openide.util.RequestProcessor.post(RequestProcessor.java:98)
        at 
org.openide.util.RequestProcessor.post(RequestProcessor.java:71)
        at 
org.netbeans.core.ModuleActions.invokeAction(ModuleActions.java:89)
        at 
org.netbeans.core.windows.frames.NbFocusManager.processKeyStroke(NbFocusM
anager.java:231)
        at 
org.netbeans.core.windows.frames.NbFocusManager.processEvent(NbFocusManag
er.java:192)
        at 
org.netbeans.core.windows.frames.NbFocusManager$1.run(NbFocusManager.java
:159)
        at 
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:160)
[catch] at java.awt.EventQueue.dispatchEvent(EventQueue.java:399)
        at 
java.awt.EventDispatchThread.pumpOneEvent(EventDispatchThread.java:109)
        at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:99)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
 
Tue Mar 20 01:54:43 EST 2001java.lang.NullPointerException: null
java.lang.NullPointerException
        at 
org.netbeans.modules.debugger.jpda.LineBreakpoint.set(LineBreakpoint.java
:107)
        at 
org.netbeans.modules.debugger.multisession.SessionBreakpoint.setBreakpoin
t(SessionBreakpoint.java:111)
        at 
org.netbeans.modules.debugger.support.BreakpointSupport.setEvent(Breakpoi
ntSupport.java:172)
        at 
org.netbeans.modules.debugger.support.BreakpointSupport.setLine(Breakpoin
tSupport.java:286)
        at 
org.netbeans.modules.debugger.support.DebuggerSupport.createBreakpoint(De
buggerSupport.java:225)
        at 
org.openide.actions.GoToCursorAction.performAction(GoToCursorAction.java:
124)
        at 
org.openide.util.actions.NodeAction.performAction(NodeAction.java:92)
        at 
org.openide.util.actions.NodeAction.actionPerformed(NodeAction.java:83)
        at org.netbeans.core.ModuleActions$1.run(ModuleActions.java:76)
        at org.openide.util.Task.run(Task.java:124)
[catch] at 
org.openide.util.RequestProcessor$ProcessorThread.run(RequestProcessor.ja
va:567)

Oh jesus.. I'm so sorry. I just re-read that stackTrace and I see now 
this is a totally different (debugger-specific) bug. Damnit.. I thought I 
had it there for a moment.. 

I'll keep on looking...

I looked more carefully at the two exceptions from the initial report
and realized that these are not two exception, but just one instead.
Why it look like two?
It is because it occured in RequestProcessor. It works the following way:
When some work is passed to the request processor, it will attach a stack
trace of the calling thread and then pass the work to the request-processor
thread. Now if some uncaught exception occur during the execution in RP,
is is caught at the bottom, annotated with the stack trace of the caller
(because caller is already doing something different for a long time) and
reported.
The exception originally occured at:
Tue Mar 06 22:53:36 EST 2001java.lang.OutOfMemoryError: null pData
java.lang.OutOfMemoryError: null pData
        at sun.awt.os2.WDialogPeer.create(Native Method)

and the first stacktrace displayed is actually the path through which the work
was passed to the request processor.
I don't know what the OOME: null pData mean, but if looks at least strange.

This is why I would like to see more stacktraces of this exception to better
undestand what is the problem.
PS: Thank you for testing the allocation in OS/2 JVM.

Something here makes no sense.. The behavior I'm getting on my end is as 
follows:

1) Simple allocation (like my testcase) always work
2) When the OutOfMemory error occurs with RequestManager it seems the JVM 
*does* have free memory so it shouldn't thrown any exception
3) Sometimes, but not always, I get OutOfMemory when the system itself is 
"almost" out of memory (ie: all real memory has been allocated but 50MB 
of swap space is left) but the JVM is not

I even used a complex process analysis tool called Theuseus for OS/2 and 
it seems to indicate that at the time of OOME the JVM only allocated 50MB 
out of 128MB.. The weird part is that I limited the JVM to 96MB, not 
128MB.. Either way, it's definately NOT out of memory..

Anyway, what I'm saying is that I'm getting a lot of mixed signals which 
makes this all the more difficult. It would be good if you could add code 
into RequestManager such that when/if it gets a OOME error it should 
auto-append "totalMemory()" and "freeMemory()" into the log so we can see 
what the values were at the time of the OOME. That *might* help ;)

I'm going to investigate this issue further on my end.

There is a strong possiblity this has to do with adding
VIRTUALADDRESSLIMIT=2048 on config.sys for OS/2 users. The default 
VIRTUALADDRESSLIMIT is 1024 (which is what I had) and in the case of Java 
programs that eat a lot of memory it might lead to a scenerio where they 
have shared memory available to them but not private memory. Upon 
increasing this value I see now private memory for java.exe has increased 
noticably. The question at hand is whether this fixes the above problem 
or not.. I will use Netbeans heavily for a week or so and report back 
whether I run into the above problem or not.

Meanwhile, I have asked Jesse Glick to add VIRTUALADDRESSLIMIT=2048 into 
the FAQ for OS/2 users so that they will avoid this problem. It should 
also go into the "installation instructions" or "requirments" document.

Well, looks like the problem with OS/2 JVM/Settings again.
It didn't happen to me unless I force IDE to be REALLY OOM by setting
it small memory limit. Did you managed to reproduce it on NT again?

Still leaving open, but awaiting your report under new settings.
Or you can close it yourself if you realize it is OK now.

I have been unable to further test this on NT (I haven't been into the 
school lab in a while).

I intend on leaving this bug open until I resolve this issue but you may 
consider it on "standby" until I come back with results. I should know 
more by next week whether I use the NT lab or not simply because I've 
adopted new settings on my end that might fix this problem anyway 
(whether this is the root of the problem or not I'm not sure of, but it 
will fix OOME anyway).

Still unresolved with new settings. I have no idea what's causing this 
problem. :(

A new version of JDK 1.3 is due out very soon so I will leave this bug 
OPEN and get back to you with the results under the new runtime when it 
is released. Hopefully there will be some change..

Sorry Gili, we have no OS/2 to debug the problem on. We will not fix it for 3.2
(if you do not provide a patch). That is why I changed the version to Dev.

That's perfectly alright. Just keep this bug open while I await an update 
for JDK 1.3.. Hopefully it will shed some more light on the issue.

Is it appropriate to change this bug to "later"?

dev, build 171

Haven't seen this error in a while.. but it seems it's back ;)

Ok, here's an update. I am now using a new JDK 1.3 from IBM (April 3rd 
release). It has some bugfixes but unfortunatelt this issue seems to 
remain unresolved so we don't know if it's a JDK issue or Netbeans yet..

     Please take a look at the exception posted below (looks a little 
different from the previous posts) and let me know if this helps you any 
or we're still in the same situation..

Sun Apr 22 01:45:43 EDT 2001: java.lang.OutOfMemoryError: Posted 
StackTrace
Annotation: Exception occurred in Request Processor
Nested annotation: null pData
org.openide.util.RequestProcessor$Holder: Posted StackTrace(task 
org.netbeans.core.ModuleActions$1@59b2a0e3 [-2102, 1, -1])
        at 
org.openide.util.RequestProcessor$Holder.<init>(RequestProcessor.java:277
)
        at 
org.openide.util.RequestProcessor$Task.createHolder(RequestProcessor.java
:322)
        at 
org.openide.util.RequestProcessor.post(RequestProcessor.java:100)
        at 
org.openide.util.RequestProcessor.post(RequestProcessor.java:73)
        at 
org.netbeans.core.ModuleActions.invokeAction(ModuleActions.java:99)
        at 
org.openide.awt.Actions$ButtonBridge.actionPerformed(Actions.java:351)
        at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1450)
        at 
javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractBu
tton.java:1504)
        at 
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.jav
a:384)
        at 
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:256)
        at javax.swing.AbstractButton.doClick(AbstractButton.java:279)
[catch] at 
javax.swing.plaf.basic.BasicMenuItemUI$MouseInputHandler.mouseReleased(Ba
sicMenuItemUI.java:946)
        at java.awt.Component.processMouseEvent(Component.java:3771)
        at java.awt.Component.processEvent(Component.java(Compiled Code))
        at java.awt.Container.processEvent(Container.java(Compiled Code))
        at java.awt.Component.dispatchEventImpl(Component.java(Compiled 
Code))
        at java.awt.Container.dispatchEventImpl(Container.java(Compiled 
Code))
        at java.awt.Component.dispatchEvent(Component.java(Compiled 
Code))
        at 
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java(Compiled 
Code))
        at 
java.awt.LightweightDispatcher.processMouseEvent(Container.java(Compiled 
Code))
        at 
java.awt.LightweightDispatcher.dispatchEvent(Container.java(Compiled 
Code))
        at java.awt.Window.dispatchEventImpl(Window.java(Compiled Code))
        at java.awt.Window.dispatchEventImpl(Window.java(Compiled Code))
        at java.awt.Component.dispatchEvent(Component.java(Compiled 
Code))
        at java.awt.EventQueue.dispatchEvent(EventQueue.java(Compiled 
Code))
        at 
java.awt.EventDispatchThread.pumpOneEvent(EventDispatchThread.java(Compil
ed Code))
        at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:99)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
 
Sun Apr 22 01:45:44 EDT 2001: java.lang.OutOfMemoryError: null pData
java.lang.OutOfMemoryError: null pData
        at sun.awt.os2.WDialogPeer.create(Native Method)
        at sun.awt.os2.WComponentPeer.<init>(WComponentPeer.java:403)
        at sun.awt.os2.WCanvasPeer.<init>(WCanvasPeer.java:33)
        at sun.awt.os2.WPanelPeer.<init>(WPanelPeer.java:91)
        at sun.awt.os2.WWindowPeer.<init>(WWindowPeer.java:93)
        at sun.awt.os2.WDialogPeer.<init>(WDialogPeer.java:36)
        at sun.awt.os2.WToolkit.createDialog(WToolkit.java:324)
        at java.awt.Dialog.addNotify(Dialog.java:248)
        at java.awt.Window.pack(Window.java:370)
        at 
org.openide.util.Utilities.showJFileChooser(Utilities.java:1312)
        at 
org.netbeans.core.actions.AddFSAction.performAction(AddFSAction.java:74)
        at 
org.openide.util.actions.CallableSystemAction.actionPerformed(CallableSys
temAction.java:66)
        at org.netbeans.core.ModuleActions$1.run(ModuleActions.java:86)
        at org.openide.util.Task.run(Task.java:141)
[catch] at 
org.openide.util.RequestProcessor$ProcessorThread.run(RequestProcessor.ja
va:612)

The actual exception (the lower part, the "second" one) is the same as
with the first example. It seems AWT implementation on OS/2 has some problems
filling data structures in the native part.
From the cryptic message "null pData", I could think there is some race
condition in their code that prevents the pData field to be properly
set up and they're abusing OutOfMemoryException for reporting it.
(Maybe the developer wrote it under the impression this state could
happen only when some malloc fail....), but this is only my speculation.
What does IBM say about this? Did you reported the problem to IBM JDK team?

I've just reported this error to IBM (sorry it took so long) so we're 
_finally_ going to get this issue resolved. Hopefully they'll find the 
problem and fix it...

... so resolved remind till we have more info from ibm.

IBM released some sort of fix and asked me to give it a whirl. 
Unfortunately I am no longer able to reproduce the problem without the 
patch (the bug seemed to disappear on its own) so I am unable to say for 
sure if this issue is really gone for good or not.

I'm going to assume the issue is closed and resolve it as such.

It's been months since I ran into this problem. I can safely say that 
it has been solved for good. Please close this issue as CLOSED FIXED, 
not CLOSED REMIND.

Thank you,

Gili

OK, resolving

closed