279132 - GC may fail to free memory automatically

Status: VERIFIED INVALID

(Core :: JavaScript Engine, defect)

Description

[Denis]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; CBOSS; .NET CLR 1.1.4322)
Build Identifier: JavaScript Engine 1.5

Here is additional version info.
VALUE "CompanyName", "Netscape Communications Corporation\0"
VALUE "FileDescription", "Netscape 32-bit JavaScript Module\0"
VALUE "FileVersion", "4.0\0"
VALUE "InternalName", "JS3240\0"
VALUE "LegalCopyright", "Copyright Netscape Communications. 1994-96            
VALUE "LegalTrademarks", "Netscape, Mozilla\0"
VALUE "OriginalFilename", "js3240.dll\0"
VALUE "ProductName", "NETSCAPE\0"
VALUE "ProductVersion", "4.0\0"

My program work for a long time. And when I don't explicitly call to GC, memory 
didn't free automatically. In result I catch spurious out_of_memory error. If I 
explicitly call to GC memory completly frees.

Reproducible: Always

Steps to Reproduce:
1. Setting error reporter function to my own.
2. Running script, creating scopes, removing scopes.
3. Second turn repeatedly working for a long time
4. In error_reporter_func I recive out_of_memory error.
5. I saw with DumpGCRoot that all rooted object - 2, and them all take small 
place. And if I explicitly run GC by JS_GC(), memory will be freed and some 
hours all will work properly
Actual Results:  
out_of_memory error

Expected Results:  
free memory automatically

Comment 1

[Denis]

Attachment: log file with macro DEBUG_brendan defined

Comment 2

[Denis]

Attachment: Scopes log file with macro DEBUG_brendan defined

Comment 3

[Denis]

I forgotten to say that all works in one context. In other words, in start I 
create runtime and context, and then many times doing same operations. May be 
it is because I'm many times do script
x='abcde';
then other operations with creation of new objects (scopes) and deleting this 
objects, and at some moment repeat
x='abcde';
May be old value didn't frees from heap? 
But seems to be like I sad.

Comment 4

[Denis]

May be it will help you.
In my researches of this problem I found that there is no much differencies in 
calls to js_GC() between automatic garbage collection and explicit call by JS_GC
(). Difference is flag = GC_KEEP_ATOMS !
Thats why automatically memory doesn't frees. In my case that ATOMS eat all 
memory...
If I edit js_api.c and write

JS_GC(JSContext *cx)
{
    if (cx->runtime->gcDisabled)
        return;

    if (cx->stackPool.current == &cx->stackPool.first)
        JS_FinishArenaPool(&cx->stackPool);
    JS_FinishArenaPool(&cx->codePool);
    JS_FinishArenaPool(&cx->tempPool);
    js_ForceGC(cx,  GC_KEEP_ATOMS );
}

Memory will not be freed by GC, even by explicit call.

Comment 5

[Denis]

Please, say..
Is it my bug of use JS Engine? Or it is real bug of JS Engine... It is very 
important for me.

Comment 6

[Brendan Eich [:brendan]]

You need to debug your embedding more to demonstrate a bug.  If you enable
GC_MARK_DEBUG and set js_LiveThingToFind to refer to an object or other gc-thing
that you believe should be collected as garbage, the GC will print the reference
path by which that thing was marked.  You can also set js_DumpGCHeap to a FILE *
to cause the heap to be dumped on every GC.  Using these techniques, you should
be able to figure out your problem.

/be

Comment 7

[Bob Clary [:bc] (inactive)]

Marking invalid. Denis, if you can get a clearer picture whether this is a bug
in the js engine rather than your embedding, please reopen.

Comment 8

[Denis]

I'm sure that error exists.
1. When JSEngine compiling scripts, it is create ATOMs.
2. That atoms cannot be freed automatically! Because automatic garbage 
collection doesn't collect atoms. 
It is clearly!
Look at source code, and in my comments to this problem.

Please, answer, is ATOMs mustn't be freed by automatic GC?

Comment 9

[Brendan Eich [:brendan]]

Stop reopening this bug to get help.  Bugzilla is not a help or support system.
 Take your reduced testcase (you need to make one from your embedding) to the
news://news.mozilla.org/netscape.public.mozilla.jseng newsgroup, state the
problem you need help fixing clearly, and ask for help.

/be

Comment 10

[Denis]

(In reply to comment #9)
> Stop reopening this bug to get help.  Bugzilla is not a help or support 
system.
>  Take your reduced testcase (you need to make one from your embedding) to the
> news://news.mozilla.org/netscape.public.mozilla.jseng newsgroup, state the
> problem you need help fixing clearly, and ask for help.
> /be


I resolved my problem by making explicit call to GC. 
I thought that it is in your interest to correct this problem. I needn't 
help. :-)
Yes, my testcase is very reduced. But may be in future this problem will be 
actual for you.

Comment 11

[Brendan Eich [:brendan]]

If your testcase is reduced, can you attach the code here, or mail it to me
(I'll keep it confidential)?  Given the many ways to leak by misusing the API,
it's not valuable to have this bug on file.  Marking it INVALID, pending further
data such as a testcase, is the only sane action.  But if you have a testcase to
share, please do so.

/be