(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #340796 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=340796 Imported into Bugzilla on 06/21/99 15:47) Company: SGI Contact: Victor Riley Phone: (650) 933-1829 Email: var@sgi.com DESCRIPTION: The following info is regarding an SGI internal application that exhibits a serious memory leak in Communicator. The stack traces point to exactly where the memory is being allocated but it is never freed and grows till the app is killed. The stack traces and analysis are the test case in this case. We will try and create a small test case but with the stack trace you should be able to locate where the memory is allocated and never freed. Email from SGI **************************************************************************** I've noticed several cases where I'm using BugWorks to submit a bug and netscape 4.5 just goes absolutely crazy allocating memory. Simply moving the mouse into and of the window once it gets into this mode is good enough to cause many KB to be allocated per entry/exit. I'm still having a hard time coming up with a reliable test case that will cause this problem. So far I've noticed it today on two ... oops, make that three different bug submissions -- this bug that I'm submitting now just started doing it. It may be associated with getting a bug text that's larger than the BugWorks text entry window. Okay, using an unstripped version of netscape these are the stack traces I'm seeing over and over again as netscape is frantically growing its break area: > 0 _brk(0x1095d000, 0x1, 0x1, 0x1094d683) ["sbrk.s":73, 0xfa2e728] 1 map_pages(0x1, 0x1, 0x1, 0x1094d683) ["prmalloc.c":523, 0x110dd70] 2 malloc_pages(0x1095d000, 0x1, 0x1, 0x1094d683) ["prmalloc.c":825, 0x110e2a8] 3 malloc_make_chunks(0xb, 0x1, 0x1, 0x1094d683) ["prmalloc.c":855, 0x110e3b4] 4 malloc_bytes(0x1095d000, 0x1, 0x1, 0x1094d683) ["prmalloc.c":922, 0x110e5d8] 5 unlocked_malloc(0x103a7300, 0x1, 0x1, 0x1094d683) ["prmalloc.c":961, 0x110e730] 6 malloc(0x50a, 0x1, 0x1, 0x1094d683) ["prmem.c":38, 0x110d9d8] 7 lm_EncodingToStr(0x10596e00, 0x2, 0x1094d400, 0x1094d683) ["lm_init.c":1950, 0xfcb4c4] 8 lm_LocalEncodingToStr(0x10516a00, 0x1094d400, 0x1, 0x1094d683) ["lm_init.c":1994, 0xfcb614] 9 lm_InputEvent(0x10516a00, 0x10874268, 0x1089e000, 0x50025f1c) ["lm_input.c":2510, 0xfda89c] 10 et_event_handler(0x1089e000, 0x1, 0x1, 0x1094d683) ["et_mocha.c":234, 0xfcbaa4] 11 PR_HandleEvent(0x1089e000, 0x1, 0x1, 0x1094d683) ["prevent.c":389, 0x10fe68c] 12 et_SubEventLoop(0x1045b120, 0x1, 0x1, 0x1094d683) ["et_mocha.c":2467, 0xfcfcb0] 13 lm_wait_for_events(0x0, 0x1048eee0, 0x1, 0x1094d683) ["et_mocha.c":2518, 0xfcfde0] 14 HopToad(0xfcfd3c, 0x0, 0x1048eee0, 0x1094d683) ["swthread.c":455, 0x10fd00c] 15 __setlinkcontext() ["setlinkctxt.s":38, 0xfae61a0] > 0 _brk(0x10a72000, 0x1, 0x2, 0x10a5e83b) ["sbrk.s":73, 0xfa2e728] 1 map_pages(0x2, 0x1, 0x2, 0x10a5e83b) ["prmalloc.c":523, 0x110dd70] 2 malloc_pages(0x10a72000, 0x1, 0x2, 0x10a5e83b) ["prmalloc.c":825, 0x110e2a8] 3 unlocked_malloc(0x103a7300, 0x1, 0x2, 0x10a5e83b) ["prmalloc.c":963, 0x110e74c] 4 malloc(0x107a, 0x1, 0x2, 0x10a5e83b) ["prmem.c":38, 0x110d9d8] 5 lm_EncodingToStr(0x10596e00, 0x2, 0x10a5e000, 0x10a5e83b) ["lm_init.c":1950, 0xfcb4c4] 6 lm_LocalEncodingToStr(0x10516a00, 0x10a5e000, 0x2, 0x10a5e83b) ["lm_init.c":1994, 0xfcb614] 7 lm_InputEvent(0x10516a00, 0x10874268, 0x106d8f00, 0x50025f1c) ["lm_input.c":2510, 0xfda89c] 8 et_event_handler(0x106d8f00, 0x1, 0x2, 0x10a5e83b) ["et_mocha.c":234, 0xfcbaa4] 9 PR_HandleEvent(0x106d8f00, 0x1, 0x2, 0x10a5e83b) ["prevent.c":389, 0x10fe68c] 10 et_SubEventLoop(0x1045b120, 0x1, 0x2, 0x10a5e83b) ["et_mocha.c":2467, 0xfcfcb0] 11 lm_wait_for_events(0x0, 0x1048eee0, 0x2, 0x10a5e83b) ["et_mocha.c":2518, 0xfcfde0] 12 HopToad(0xfcfd3c, 0x0, 0x1048eee0, 0x10a5e83b) ["swthread.c":455, 0x10fd00c] 13 __setlinkcontext() ["setlinkctxt.s":38, 0xfae61a0] > 0 _brk(0x10a70000, 0x1, 0x1, 0x10a5b83b) ["sbrk.s":73, 0xfa2e728] 1 map_pages(0x1, 0x1, 0x1, 0x10a5b83b) ["prmalloc.c":523, 0x110dd70] 2 malloc_pages(0x10a70000, 0x1, 0x1, 0x10a5b83b) ["prmalloc.c":825, 0x110e2a8] 3 unlocked_malloc(0x103a7300, 0x1, 0x1, 0x10a5b83b) ["prmalloc.c":963, 0x110e74c] 4 malloc(0x83d, 0x1, 0x1, 0x10a5b83b) ["prmem.c":38, 0x110d9d8] 5 _strdup(0x10a5b000, 0x1, 0x1, 0x10a5b83b) ["strdup.c":30, 0xfa397d0] 6 fe_lost_focus_cb(0x106dc800, 0x10649ae0, 0x7fff1524, 0x10a5b83b) ["forms.c":1934, 0x6c6d98] 7 XtCallCallbackList(0x106dc800, 0x10649d80, 0x7fff1524, 0x10a5b83b) ["Callback.c":672, 0xf644bd8] 8 VerifyLeave(0x10a70000, 0x7fff1734, 0x1, 0x10a5b83b) ["TextIn.c":6013, 0x40cd4f4] 9 TextFocusOut(0x106dc800, 0x7fff1734, 0x0, 0xf6c2df0) ["TextIn.c":6092, 0x40cc31c] 10 HandleActions(0x106dc800, 0x7fff1734, 0x1, 0x106dc800) ["TMstate.c":621, 0xf6420c4] 11 HandleSimpleState(0x106dc800, 0x1, 0x7fff1660, 0x10a5b83b) ["TMstate.c":853, 0xf641ea0] 12 _XtTranslateEvent(0x10a70000, 0x1, 0x1, 0x106dc800) ["TMstate.c":1070, 0xf641b60] 13 XtDispatchEventToWidget(0x106dc800, 0x7fff1734, 0x1, 0x0) ["Event.c":1034, 0xf640ed4] 14 _XtSendFocusEvent(0x106dc800, 0xa, 0x1, 0x10a5b83b) ["Event.c":1786, 0xf63fa74] 15 _XtHandleFocus(0x10508e00, 0x10576920, 0x7fff1908, 0x7fff17f9) ["Keyboard.c":611, 0xf63fdd4] 16 XtDispatchEventToWidget(0x10508e00, 0x7fff1908, 0x1, 0xf64034c) ["Event.c":1001, 0xf640e10] 17 _XtDefaultDispatcher(0x7fff1908, 0x1, 0x1, 0x10a5b83b) ["Event.c":1474, 0xf640488] 18 XtDispatchEvent(0x10a70000, 0xf640244, 0x7fff1908, 0x103e2400) ["Event.c":1571, 0xf640958] 19 XtAppProcessEvent(0x103e2400, 0x1, 0x1, 0x10a5b83b) ["NextEvent.c":1459, 0xf644aa4] 20 fe_EventLoop(0x10a70000, 0x1, 0x1, 0x10a5b83b) ["mozilla.c":1086, 0x706074] 21 main(0x1, 0x7fff2ef4, 0x0, 0x10a5b83b) ["mozilla.c":3692, 0x70a1dc] 22 __istart() ["crt1tinit.s":13, 0x6a5ef0] > 0 _brk(0x10a82000, 0x1, 0x2, 0x10a5e83b) ["sbrk.s":73, 0xfa2e728] 1 map_pages(0x2, 0x1, 0x2, 0x10a5e83b) ["prmalloc.c":523, 0x110dd70] 2 malloc_pages(0x10a82000, 0x1, 0x2, 0x10a5e83b) ["prmalloc.c":825, 0x110e2a8] 3 unlocked_malloc(0x103a7300, 0x1, 0x2, 0x10a5e83b) ["prmalloc.c":963, 0x110e74c] 4 malloc(0x107a, 0x1, 0x2, 0x10a5e83b) ["prmem.c":38, 0x110d9d8] 5 lm_EncodingToStr(0x10596e00, 0x2, 0x10a5e000, 0x10a5e83b) ["lm_init.c":1950, 0xfcb4c4] 6 lm_LocalEncodingToStr(0x10516a00, 0x10a5e000, 0x2, 0x10a5e83b) ["lm_init.c":1994, 0xfcb614] 7 lm_InputEvent(0x10516a00, 0x10874268, 0x1089e300, 0x50025f1c) ["lm_input.c":2510, 0xfda89c] 8 lm_KeyInputEvent(0x10a82000, 0x1, 0x1089e300, 0x50025f1c) ["lm_input.c":2053, 0xfd9910] 9 et_event_handler(0x1089e300, 0x1, 0x2, 0x10a5e83b) ["et_mocha.c":221, 0xfcba5c] 10 PR_HandleEvent(0x1089e300, 0x1, 0x2, 0x10a5e83b) ["prevent.c":389, 0x10fe68c] 11 et_SubEventLoop(0x1045b120, 0x1, 0x2, 0x10a5e83b) ["et_mocha.c":2467, 0xfcfcb0] 12 lm_wait_for_events(0x0, 0x1048eee0, 0x2, 0x10a5e83b) ["et_mocha.c":2518, 0xfcfde0] 13 HopToad(0xfcfd3c, 0x0, 0x1048eee0, 0x10a5e83b) ["swthread.c":455, 0x10fd00c] 14 __setlinkcontext() ["setlinkctxt.s":38, 0xfae61a0] > 0 _brk(0x10a7a000, 0x1, 0x1, 0x10a5b83b) ["sbrk.s":73, 0xfa2e728] 1 map_pages(0x1, 0x1, 0x1, 0x10a5b83b) ["prmalloc.c":523, 0x110dd70] 2 malloc_pages(0x10a7a000, 0x1, 0x1, 0x10a5b83b) ["prmalloc.c":825, 0x110e2a8] 3 unlocked_malloc(0x103a7300, 0x1, 0x1, 0x10a5b83b) ["prmalloc.c":963, 0x110e74c] 4 malloc(0x83d, 0x1, 0x1, 0x10a5b83b) ["prmem.c":38, 0x110d9d8] 5 _strdup(0x10a5b000, 0x1, 0x1, 0x10a5b83b) ["strdup.c":30, 0xfa397d0] 6 fe_lost_focus_cb(0x106dc800, 0x10649ae0, 0x7fff1334, 0x10a5b83b) ["forms.c":1934, 0x6c6d98] 7 XtCallCallbackList(0x106dc800, 0x10649d80, 0x7fff1334, 0x10a5b83b) ["Callback.c":672, 0xf644bd8] 8 VerifyLeave(0x10a7a000, 0x7fff1544, 0x1, 0x10a5b83b) ["TextIn.c":6013, 0x40cd4f4] 9 TextFocusOut(0x106dc800, 0x7fff1544, 0x0, 0xf6c2df0) ["TextIn.c":6092, 0x40cc31c] 10 HandleActions(0x106dc800, 0x7fff1544, 0x1, 0x106dc800) ["TMstate.c":621, 0xf6420c4] 11 HandleSimpleState(0x106dc800, 0x1, 0x7fff1470, 0x10a5b83b) ["TMstate.c":853, 0xf641ea0] 12 _XtTranslateEvent(0x10a7a000, 0x1, 0x1, 0x106dc800) ["TMstate.c":1070, 0xf641b60] 13 XtDispatchEventToWidget(0x106dc800, 0x7fff1544, 0x1, 0x0) ["Event.c":1034, 0xf640ed4] 14 _XtSendFocusEvent(0x106dc800, 0xa, 0x1, 0x10a5b83b) ["Event.c":1786, 0xf63fa74] 15 XtSetKeyboardFocus(0x10508e00, 0x0, 0x1, 0x10a5b83b) ["Keyboard.c":792, 0xf648b14] 16 _XmMgrTraversal(0x106dc800, 0x0, 0x1, 0x106dc800) ["Traversal.c":819, 0x40840e0] 17 XmProcessTraversal(0x106dc800, 0x0, 0x1, 0x10a5b83b) ["Traversal.c":1779, 0x409a0c8] 18 DoGrabFocus(0x106dc800, 0x7fff1908, 0x0, 0xf6c2df0) ["TextIn.c":4894, 0x40ccdc0] 19 HandleActions(0x106dc800, 0x7fff1908, 0x1, 0x106dc800) ["TMstate.c":621, 0xf6420c4] 20 HandleSimpleState(0x106dc800, 0x1, 0x7fff1760, 0x10a5b83b) ["TMstate.c":853, 0xf641ea0] 21 _XtTranslateEvent(0x10a7a000, 0x1, 0x1, 0x106dc800) ["TMstate.c":1070, 0xf641b60] 22 XtDispatchEventToWidget(0x106dc800, 0x7fff1908, 0x1, 0xf6405dc) ["Event.c":1034, 0xf640ed4] 23 _XtDefaultDispatcher(0x7fff1908, 0x1058c800, 0x1, 0x10a5b83b) ["Event.c":1508, 0xf6406a4] 24 XtDispatchEvent(0x10a7a000, 0xf640244, 0x7fff1908, 0x103e2400) ["Event.c":1571, 0xf640958] 25 XtAppProcessEvent(0x103e2400, 0x1, 0x1, 0x10a5b83b) ["NextEvent.c":1459, 0xf644aa4] 26 fe_EventLoop(0x10a7a000, 0x1, 0x1, 0x10a5b83b) ["mozilla.c":1086, 0x706074] 27 main(0x1, 0x7fff2ef4, 0x0, 0x10a5b83b) ["mozilla.c":3692, 0x70a1dc] 28 __istart() ["crt1tinit.s":13, 0x6a5ef0] As can be seen, there seems to be two stack trace patterns here. One revolves around this fragment: 4 malloc(0x107a, 0x1, 0x2, 0x10a5e83b) ["prmem.c":38, 0x110d9d8] 5 lm_EncodingToStr(0x10596e00, 0x2, 0x10a5e000, 0x10a5e83b) ["lm_init.c":1950, 0xfcb4c4] 6 lm_LocalEncodingToStr(0x10516a00, 0x10a5e000, 0x2, 0x10a5e83b) ["lm_init.c":1994, 0xfcb614] 7 lm_InputEvent(0x10516a00, 0x10874268, 0x10756000, 0x50025f1c) ["lm_input.c":2510, 0xfda89c] and the other around this fragment: 4 malloc(0x83d, 0x1, 0x1, 0x10a5b83b) ["prmem.c":38, 0x110d9d8] 5 _strdup(0x10a5b000, 0x1, 0x1, 0x10a5b83b) ["strdup.c":30, 0xfa397d0] 6 fe_lost_focus_cb(0x106dc800, 0x10649ae0, 0x7fff1524, 0x10a5b83b) ["forms.c":1934, 0x6c6d98] I've looked at the strings being passed as the second argument to lm_LocalEncodingToStr() and the first argument to strdup() and it seems like the strings contain the entire current contents of my bug report. It's almost as if netscape is reallocating the entire bug report text string (for some completely unknown reason on entry/exit) and not bothering to free up the old version. ******************************************************************************* ************************************* *** January 26, 1999 8:21 AM *** kysmith *** Called customer and asked for a test case, they are working on one but think the stack traces they have provided should show us where the problem is in our code. *** January 26, 1999 8:22 AM *** kysmith *** This is a showstopper for SGI's work to include 4.5 in their OS. If we don't fix this in 4.51, they will not put 4.51 into their OS. Here's comments from their lead stress tester ******************************************************************************* ** I'm giving up completely on netscape 4.50 and am downgrading to 4.07 in the 6.5.3 images. I consider netscape 4.50 to be a complete loss at this point because of this bug. If this bug isn't addressed in the next version of netscape it will also be a complete loss. I will vote against taking any version of netscape into the IRIX 6.5 release stream which has this bug in it. ******************************************************************************* ***

Adding markek,jpm, and hannigan to Cc for assessment.

kysmith, since this is a memory leak problem can you supply with us with specific environment variables they reproduced this bug on. *** January 27, 1999 10:33 AM *** kysmith *** Email rec'd from customer, I am still asking for a test case. ******************************************************************** Would the output of the CGI that causes the bloat be useful? Here is a link to info in our defect tracking system on this issue. View Incident: http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view _type=Bug&wi=662007 Here are answers to your questions | 1 - What version of IRIX was it seen on? IRIX 6.5.3m | 2 - What is the version of windowing environment? X V11R6 with twm | 3 - how much RAM on machine? 128MB | 4 - df -k output from machine Filesystem Type kbytes use avail %use Mounted on /dev/root xfs 988660 897140 91520 91 / /dev/dsk/dks0d2s7 xfs 2092792 1117368 975424 54 /usr/people | 5 - listing of env variables in shell of user who can reproduce | the problem _=/usr/bin/X11/xterm MANPATH=/usr/catman:/usr/share/catman:/usr/share/local/catman:/usr/local/man:/u sr/freeware/catman:/usr/freeware/man:/usr/people/leedom/man LANG=C RNINIT=-h hFrom hOrganization hSubject hSummary hKeywords hDate -F -ESAVEDIR=/usr/people/leedom/tmp -EATTRIBUTION='From: %f' -EYOUSAID='From: %f' PROJ=/hosts/bonnie.engr/proj PAGER=/usr/freeware/bin/less HOMEHOST=gauss.engr.sgi.com PATH=/usr/people/leedom/bin:/usr/etc:/usr/sbin:/usr/bin:/usr/bin/X11:/etc:/sbin :/bin:/usr/bsd:/usr/local/bin/ptools:/usr/local/bin:/usr/freeware/bin:/usr/fram e/bin:/usr/annex:/usr/pure/purify:. TREES=/usr/people/leedom/roots NOMSGLABEL=1 HOMEHOST_ABREV=gauss.engr NNTPSERVER=news.engr.sgi.com. HOSTNAME_ABREV=gauss.engr EDITOR=/usr/people/leedom/bin/jove PMAKE=-J2 LOGNAME=leedom TRINIT=-m=u -N HOSTNAME=gauss.engr.sgi.com SOCKS_SERVER=192.26.51.11 LISTS=/hosts/relay.engr/var/domain/Lists/Majordomo FRAMEUSERSD_HOST=newmedia.esd.sgi.com. PRINTER=earthquake HOST=gauss.engr.sgi.com STTY=line 1 intr ^C quit ^\ erase ^H werase ^W kill ^U rprnt ^R flush ^O eof ^D susp ^Z stop ^S start ^Q lnext ^V -ignbrk brkint -inpck -istrip -inlcr -igncr icrnl -iuclc ixon -ixany -ixoff -imaxbel opost -olcuc onlcr -ocrnl -onocr -onlret -ofill isig icanon -xcase -noflsh echo echoe -echok echoke echoctl -echoprt echonl USER=leedom SHLVL=1 MSGVERB=text:action RDISPLAY=gauss.engr.sgi.com:0 LASTLOGIN=Last login: Thu Jan 21 09:20:00 PST 1999 by guest@fitness.engr.sgi.com SOCKS_NS=192.26.51.11 DISPLAY=:0.0 SHELL=/bin/tcsh HOSTTYPE=iris4d X=/usr/people/leedom/X ORGANIZATION=Silicon Graphics, Inc. AUTOUNSUBSCRIBE=alt\..* HOME=/usr/people/leedom NETHACKOPTIONS=time,fixinv,notombstone,name:leedom-S,dogname:Pointlessly Stupid,catname:Pointlessly Stupid MORE=-c TERM=xterm XAPPLRESDIR=/usr/people/leedom/X/app-defaults FMHOME=/usr/frame PWD=/usr/people/leedom TZ=PST8PDT LPDEST=earthquake LESS=-Qmecs NOMSGSEVERITY=1 WINDOWID=33554446 TIME=%Uu %Ss %E %P %wwait %cswt %ksig %I %Oio %Fpf %Rpr %Wswp WHOAMI=leedom | 6 - Is it possible for you to try this on win95 and see if the | leak occurs there? No; I don't have access to any win95 machine | 7 - last but not least...is it possible to get a test case from | you? What do you think Victor? Could we send them the output of a BugWorks UPDATE or ADD form? I'm pretty convinced that the problem is being caused by something wacko in the text description type-in form window (or whatever the correct nomanclature for it is). *** January 27, 1999 10:35 AM *** kysmith *** I'm asking customer to attempt to reproduce on IRIX 6.2 *** January 28, 1999 9:16 AM *** kysmith *** met with customer yesterday and explained to them we will not get much action on this defect until we get a test case from them. They agreed. I'm downgrading to a TS2 until we get the test case. *** January 29, 1999 12:37 PM *** kysmith *** Rec'd test case from customer. To reproduce this defect: 1 - fire up 4.5 on NT 2 - fire up NT Task Manager and click on Processes tab 3 - find the netscape.exe process and observe how much memory it's using. 4 - surf to http://rocknroll/users/kysmith/publish/Calls/97386/bwxupdate.html 5 - find the large multi-line field labeled "Description" about 1/5 of the way down the page 6 - click on this box and begin entering text, complete with <CR>s 7 - enter enough text to create scroll bars on the side and bottom of the field 8 - click on the NT desktop 9 - click back inside the field where you typed the text in step 6 10 - repeat steps 8 and 9 a few times while observing the memory used by netscape.exe 11 - after about 5 or 10 clicks the memory usage will start growing and will not be released until you exit the page.

rodney, pls reproduce 4.51 list is frozen - setting TFV 4.52

I am confused now with the testcase that you have posted. Is this a Windows NT specific problem or is this a Irix 6.2 problem? *** February 1, 1999 1:24 PM *** kysmith *** Wups my mistake...this is a winNT defect...sorry 'bout that.

Problem happens on 4.51 M2 for NT

Problem also reproduces on 4.51M2 for Solaris. *** February 9, 1999 6:51 AM *** kysmith *** SGI requests we escalate this so we get a fix into 4.51. They wish to bundle 4.51 with their OS version 6.5.4 but the memory leak will prevent that.

reassigning to marek *** February 12, 1999 10:58 AM *** kysmith *** Here is the business case to fix this one. ************************** SGI wishes to bundle 4.51 in their OS release 6.5.4 (which is due in May) but this defect will stop them from doing so. Their current release (6.5.3) includes 4.07 browser code so to date they have not gotten a version of IRIX out w/ 4.5X in it. There are many improvements in 4.5X compared to the 4.0X product line and SGI wishes to offer these improvements to their customers. SGI is working on signing a localization agreement for 4.5X that will give Netscape $90K. If SGI can't roll to 4.51 in the 6.5.4 release then this payment would be defered for a few quarters while their 6 month localization cycle spins again and into the 6.5.6 release - if there is one. At that time there might be a 5.0 product which may not require localization due to the open source and thus SGI wouldn't need to sign an agreement and Netscape would not get the $90K. ************************* *** February 12, 1999 4:24 PM *** kysmith *** Excerpt from an email rec'd from SGI offering engineering help on this issue ******** If you need SGI engineers to help resolve that issue we are willing to come over there to help, but a run with purify should pinpoint the problem very quickly. ********

we will not be able to provide SGI with a fix in the 4.51 timeframe. Please notify them that the next sustaining release for 4.6 is set tenatively around April. We may need help from SGI engineers to help pinpoint this problem, but that will be at a later time. Right now all of the engineers are focusing on releasing 4.51 with the current 4.51in bug list.

assigning to serge for consideration in 4.52

Yes, it does allocate some memory when some events occur. Actually, libmocha saves any TEXTAREA content on several events, but later on closing current document javascript GC will free it. So SGI's sentence: "It's almost as if netscape is reallocating the entire bug report text string (for some completely unknown reason on entry/exit) and not bothering to free up the old version" is WRONG. I'm not sure if there is some unrisky way to fix this, because all 4.0x work in the same way.

Clayton and Norris, is there a safe way to run the garbage collection before a user closes the page?

Fur, would you comment on the GC question at the end of this bug report? And pass on to Dave Price <dprice>? Thanks, = C =

This does not sound like a GC problem because JavaScript GC runs every time a page is unloaded, but the claim is that the memory is not free'ed until the app exits and presumably at least one other page is loaded/unloaded in the interim. This looks like a plain old case of failing to free an allocated string. In any case, it should be safe to request a GC at any time on the mocha thread, i.e. by calling JS_GC(). As a test, you might try doing this for every received event, which will certainly be slow, but can be used as a diagnostic.

Setting TFV to 4.6. This implies that all these bugs will be considered for fix in 4.6, but there is no guarantee that they will be. More triage needs to be done.

fur, are you still looking at this or as per clayton's request should this be passed on to dprice?

I didn't realize the bug was assigned to me. Assigning to dprice.

setting TFV to 4.6in per bug triage

trix, be ready to work with serge on a QA plan for this when it checks in

Clayton, we need help from someone in the main Javascript group on this one. Could you help?

Clayton, we need help from someone in the main Javascript group on this one. Could you help?

Mike, would you work with Marek's team on this leak? I nominate you as SGI aware engineer of the month. I expect that Marek will pair you with someone on his team to debug together until the source of the leak appears - you providing some debug knowledge both of SGI and the engine itself. Then we can figure out who should handle the fix as a second issue. Thanks, = C =

I can help with poking in JS_GC() calls. I'm not particularly familiar with libmocha, however - if this is urgent, I'm probably not the best person to own this. (I build on an SGI, but this doesn't seem to be an SGI-specific problem.) Other takers?

I'll do what I can to help. Can someone from Marek's team contact me?

David, please work with Norris on this one. Thanks.

I spent some time with Norris this morning. It looks like this problem is related to another problem with the Garbage Collector. Norris agreed to test my sample in a build with the other fix. Two birds with one stone? We should be so lucky.

The leak disappears when you remove the name attribute from the <TEXTAREA>. Norris and I are still looking in to why that is, and why the memory isn't being collected. An immediate workaround would be to remove the name attribute from the <TEXTAREA> tag. I checked the source for the test case, and the name isn't referenced anywhere else in the page.

This bug requires the fix for 345701 as well. I have a fix for this with one minor change on top of the fix for 345701. dprice has reviewed the fix.

This wasn't really a leak, but a failure to run gc. The fix for 345701 fixes most of this, and the addition of a gc poke in JS_SetRegExpInput makes this test case work. Fixed in Nav45_BRANCH: Checking in jsapi.c; /m/src/ns/js/src/Attic/jsapi.c,v <-- jsapi.c new revision: 1.60.4.1.18.4; previous revision: 1.60.4.1.18.3 done Checking in jscntxt.h; /m/src/ns/js/src/Attic/jscntxt.h,v <-- jscntxt.h new revision: 1.21.36.5; previous revision: 1.21.36.4 done Checking in jsgc.c; /m/src/ns/js/src/Attic/jsgc.c,v <-- jsgc.c new revision: 1.25.8.1.18.3; previous revision: 1.25.8.1.18.2 done Checking in jsinterp.c; /m/src/ns/js/src/Attic/jsinterp.c,v <-- jsinterp.c new revision: 1.72.4.1.18.5; previous revision: 1.72.4.1.18.4 done Checking in jsparse.c; /m/src/ns/js/src/Attic/jsparse.c,v <-- jsparse.c new revision: 1.39.6.2.2.5; previous revision: 1.39.6.2.2.4 done Needs to be propagated to the 4.51 OEM branch.

Merged fix to 451OEM Branch

doing some load balancing here -- changing QA assigned to hong - pls verify asap - d

I am reopening this bug. I am still getting a failure to free memory on Solaris 2.5.1, running the March 31 4.51 OEM build. If you run the testcase outlined in this bugreport, and monitor the virtual memory in use via Solaris' Workstation Information applet, you will see that memory is not released even after you close the page. The fix works on Windows NT 4.0, however. From reading the description of the bug, this seems like a cross platform bug. Should dprice and norris' fix work on all platforms? Please advise. Reopening.

There wasn't anything platform specific in the fix we put in. I can only guess that there's some other problem that is preventing the collector from running. I'm not particularly Unix savvy; can dprice or someone get a debug build on that platform and I'll take a look?

Using Irix6.2's built in gmemory monitor, and Linux' xsysinfo applet, and the March 31 OEM build, I note that with the given testcase, memory is still being allocated at a fast rate and not being deallocated, despite page load/unload. As compared to WinNt, where memory is reclaimed almost immediately upon a new page load, there is no reclamation on any of the unix platforms i have tested (Solaris, IRIX and Linux Redhat) until the application exits. Leaving REOPENED.

Perhaps a related problem from the netscape.public.mozilla.jseng newsgroup: Subject: Memory leak on JS Engine arrays Date: Tue, 30 Mar 1999 17:44:38 0200 From: "Lionel Touati" <ltouati@ogilvy.net> Organization: Another Netscape Collabra Server User Newsgroups: netscape.public.mozilla.jseng Hi, I've got huge problems with arrays, on my IRIX computer. When using below script, the GC doesn't free back memory, nor reuse it... I've compiled latest src version from mozilla.org, and still have the problem... I think it must be something like a compile option, because the same script on NT sends back memory... Thanks a lot for your answer anArray = new Array(500); for(i=0;i<500;i ) { anArray[i] = new Array(500); } for(i=0;i<500;i ) for(j=0;j<500;j ) { anArray[i][j] = "trgedgfjdk"; } print("Freeing memory \n"); for(i=0;i<500;i ) { for(j=0;j<500;j ) { delete anArray[i][j]; } delete anArray[i]; } print("Freeing memory done\n"); delete anArray; print("Sleeping \n"); for(i=0;i<100000;i );

I'm adding serge to the cc list. He's in the process of making a recent unix debug build. serge could you let norris know where the build lives?

the latest solaris2.5 build is in /h/sergesupreme/export4/client/46 the next dirs were built with -g: ns/cmd/xfe, ns/js/src, ns/lib/libmocha

Thanks for making the build. I found a machine and am able to run it, but when I try to start with gdb, I get an error message: "/usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1": not in executable format: File format not recognized. Do I need to use some platform debugger?

norris, I will forward this to serge with your questions

sorry, I missed it somehow:( norris, try 'which gdb' is should be from /tools/ns/bin.

norris, any update on this?

Scott, can you own this now?

Whats going on here??? is anyone looking at this?? please update

norris will no longer be responsible for JavaScript/libmocha bugs. I'm happy to help out dprice or anyone else tracking this bug down, but I would appreciate it if some detective work gets done ahead of time, e.g. using Purify, to see what leaks, if any remain after fixing the original bug. Until then, I'm passing the buck to dprice.

I'm setting the TFV to 4.61 ------- Additional Comments From dprice May-17-1999 20:00 ------- TFV=4.7 ------- Additional Comments From dprice May-17-1999 20:29 ------- *** Bug 343745 has been marked as a duplicate of this bug. *** ------- Additional Comments From jpm Jun-04-1999 16:25 ------- Fix too risky for 4.x; setting TFV 5.0. Clayton, can you please have this moved to bugzilla for 5.0 if this is a issue for Seamonkey as well? Thanks - Jussi- Pekka ------- Additional Comments From clayton Jun-07-1999 15:03 ------- Dave, 4.5 bug that won't be the same problem in Seamonkey. Do you want to put it on ice? ------- Additional Comments From dprice Jun-07-1999 17:40 ------- Since this won't be a problem in 5.0 I'm resolving this as won't fix ------- Additional Comments From jdunn Jun-07-1999 17:46 ------- This is fixed in 5.0. The routines have been modified such that in 5.0 this will not be a problem. NOTE: this will NOT BE FIXED in the 4.x codebase ------- Additional Comments From jdunn Jun-10-1999 12:22 ------- *** Bug 332807 has been marked as a duplicate of this bug. *** ------- Additional Comments From hong Jun-21-1999 14:06 ------- Jan, we are moving this off the 4.x radar permanently and into the 5.0 codebase, can you QA assign this to the proper person? Thanks.. H ------- Additional Comments From leger Jun-21-1999 14:31 ------- Setting QA Assigned to cbegle to Verify with latest Seamonkey build and Javascipt. cbegle, does this correct for 5.0? ------- Additional Comments From cbegle Jun-21-1999 15:19 ------- nope. maybe beth can reassign? thanks ------- Additional Comments From beppe Jun-21-1999 15:49 ------- I am moving this bug to bugzilla, I just talked with Victor and he will verify the fix and include appropriate comments.

mid-air collision ? / bugzilla cleanup Reopening (current State: resolved and no resolution)

marking Wontfix