Is there a memory leak in Aperture 3.5?

Aperture 3.5
Mac mini (late 2012), 16GB RAM
OSX 10.9
I’ve been doing some phto editing work in Aperture recently. This has involved painting in Curve adjustments. It’s been getting pretty slow. Then this window appeared.
Looking at Activity Monitor, I found that memory had become rather tight. After I quit Aperture, the memory pane zipped down to green levels. See comparison screenshot here:
You can actually see the point where Aperture is quit - a massive drop in memory pressure. It seems that as I edit images in Aperture (and it appears that brushing in adjustments is the culprit - I only need to do two or three images before this starts to get serious), the memory pressure increases to a point where it seems to blow a gasket, and I am invited to quit applications.
The images are shot in RAW, and are 14MP in size.

Hi SierraDragon,
Yes I have a decent Mac, at least I think.
I have a late 2011 17inch i7 Macbook Pro with 16G ram and 512 SSD.
Something seems to be hogging the memory and not releasing it when I was using Aperture. It will virtually continue to use the memory until it got to ZERO!
I do notice, everytime I scroll to the next RAW image, at least a few hundred mac is gone, zoom in to the picture takes another few hundred. That's a giga byte per image. So after about 10 images, my 16G is gone.
This is weird. Yes Aperture will continue to use my SSD as virtual memory but I do notice performance drop, even with SSD and I can image someone who has a traditional hard drive will suffer terribly.
I also use Activity Monitor to see the memory usage and it also seems that there's a big chuck goes to file cache!! I think that's Aperture's image preview when I scrolling through images. But they should be released as soon as I move to the next or two.
That's poor execution I imagine but i am no technical guy so I don't really know. I am just trying to find a solution so I can get some work done. I have to use Adobe Lightroom as a back up at the moment but it isn't my favourite image processor.
Jimmy

Similar Messages

Is there a memory leak in IXML library?

Hi,
I wonder if there is a memory leak in the IXML library. Using the memory inspector I observed that memory consumed while building a DOM-tree is never released. Is there some special cleanup method I have to call to free all memory consumed by my DOM tree? I tried to explicitly remove the node to free memory, but that seems not to work (look at my example report below).
Regards,
Michael
REPORT Z_IXML_TEST .
data:
lr_ixml type ref to if_ixml,
lr_dom type ref to if_ixml_document,
lr_element type ref to if_ixml_element,
l_rc type i.
class cl_ixml definition load.
lr_ixml = cl_ixml=>create( type = 0 ).
lr_dom = lr_ixml->create_document( ).
at this point you see 1 string in Memory Inspector after creating a snapshot
lr_element = lr_dom->create_element( name = 'root' ).
call method lr_element->set_attribute( name = 'attrName1' value = 'attrValue1' ).
call method lr_element->set_value( value = 'value1' ).
call method lr_dom->append_child( new_child = lr_element ).
at this point you see 5 strings in Memory Inspector after creating a snapshot
l_rc = lr_dom->remove_child( old_child = lr_element ).
lr_element->remove_node( ).
lr_dom->remove_node( ).
free lr_element.
free lr_dom.
free lr_ixml.
at the latest at this point you would expect 1 string again, but there are still 5!

Answer in
SAP Note 1081257 Memory leak in the iXML library

Is there any memory leaks in the version 4.6.21?

Hi All:
My en so weak ,so I try my best to let you understand my mean...
I add replication to my app rencently.
It's seem any memory leaks in the version 4.6.21.
Threr is an env in my app's database. and there are 2000 dbs in the env. The 2000 dbs distributing In 200 directory . And the 200 directory is the subdirectory under the DATADIR.
In the app, client and master create all subdirectory befoer the env been opened . And In my test ,if the master app use relative path to create Db and r/w data, the data will be correct send to client, The data in the master and client will keep identical.
But, There is many memory leaks in the app.In my test ,the app will use up all memory that lead malloc failed and crash.
the app use DB_LOG_AUTOREMOVE,DB_LOG_INMEMORY,DB_REPMGR_ACKS_NONE.
cache_size = 500M.
void event_callback(DbEnv* dbenv, u_int32_t which, void *info)
     bool * isMaster = (bool *)dbenv->get_app_private();
     info = NULL;                    /* Currently unused. */
     switch (which) {
     case DB_EVENT_REP_MASTER:
          *isMaster = 1;
          dbenv->errx("switch to master mode");
          break;
     case DB_EVENT_REP_CLIENT:
          *isMaster = 0;
          dbenv->errx("switch to slaver mode");
          break;
     case DB_EVENT_REP_STARTUPDONE: /* FALLTHROUGH */
     case DB_EVENT_REP_NEWMASTER:
     case DB_EVENT_REP_PERM_FAILED:
          // I don't care about this one, for now.
          break;
     default:
          dbenv->errx("ignoring event %d", which);
Thanks
d.j
Message was edited by:
user623248

I setup logdir,datadir and envdir into different directories with
the functions set_data_dir and set_log_dir.I created two directories
under the datadir and created more than 100 sub-directories
respectively for the two dir, where the 2000 databases located.By the way, even though it doesn't seem likely to be the cause of the
memory leak, you should still fix this illegal usage of subdirectories
before we get much further investigating. We might as well eliminate
any possible source of problem, no matter how unlikely it seems.
Also, just as an experiment, I would be very tempted to try running
again without using any separate directories. In other words, don't
call set_data_dir or set_log_dir at all, and just let everything be
put into the one single directory. If that changes the results, that
will be a big clue to help us know where to look for the problem.
I'am writting a demo , but it take time.
i will reply later .Thank you. Take your time -- we'll be here.
Alan Bram
Oracle

Firefox 4.0.1 is using 130 - 160mb of memory on Win7 and I'm getting a memory low error. Is there a memory leak on Firefox

I start getting a memory low warning in Windows 7 and the task manager shows Firefox as 130mb peaking at 160mb. Surely this is much too high and I wondered if there was a creeping memory leak going on. I've disabled most add-ons

Sorry didn't noticed it was solved.

Memory leak in jvm? totalMemory differs real memory usage

I working on a server application under linux with java 1.4.1_02.
The problem is that the OS reports after approx. 2 days a memory usage of about 200 MB while the JVM's totalMemory method says, that only about 20 MB are allocated and more than 10 MB of these 20 MB are free. Calling System.gc() doesn't help.
Is there a memory leak in the JVM itself ?
Is there a bugfix or workaround for preventing out of memory ?

hi, here is some of the messages from our tomcat log. Please let us know if you see something here.
thanks
wh
14:04 Started Tomcat0.000: [GC 23352K->3056K(259264K), 0.0425550 secs]
6.396: [GC 26416K->3837K(259264K), 0.0428260 secs]
67.830: [GC 27197K->7675K(259264K), 0.0526750 secs]
14:11 Started OpenSTA load test (Tomcat 103M/103M SIZE/RSIZE)417.805: [Full GC 23900K->10468K(259264K), 0.1470690 secs]
464.368: [Full GC 29592K->12380K(259264K), 0.1984410 secs]
474.295: [GC 35740K->16076K(259264K), 0.0362230 secs]
482.470: [Full GC 32672K->16120K(259264K), 0.1574280 secs]
497.299: [Full GC 32266K->15347K(259264K), 0.1993480 secs]
513.132: [GC 38707K->15644K(259264K), 0.0067610 secs]
513.552: [Full GC 21105K->15833K(259264K), 0.1484350 secs]
524.393: [Full GC 31980K->15975K(259264K), 0.1507760 secs]
535.314: [Full GC 36832K->16164K(259264K), 0.1561530 secs]
544.704: [GC 39524K->16360K(259264K), 0.0035200 secs]
544.724: [Full GC 17439K->15435K(259264K), 0.1654420 secs]
550.837: [GC 38790K->15669K(259264K), 0.0031210 secs]
550.961: [Full GC 20198K->15612K(259264K), 0.1458520 secs]
561.816: [Full GC 36712K->15768K(259264K), 0.1535080 secs]
567.997: [Full GC 38928K->15944K(259264K), 0.1586890 secs]
572.313: [Full GC 29129K->15618K(259264K), 0.1764170 secs]
581.769: [Full GC 36749K->15768K(259264K), 0.1538980 secs]
588.514: [GC 39123K->16114K(259264K), 0.0042700 secs]
588.573: [Full GC 20576K->15878K(259264K), 0.1476950 secs]
592.833: [Full GC 34359K->16027K(259264K), 0.1563230 secs]
594.394: [GC 39387K->16189K(259264K), 0.0030660 secs]
596.453: [Full GC 30677K->15678K(259264K), 0.1698180 secs]
603.878: [GC 39038K->15839K(259264K), 0.0043830 secs]
610.088: [Full GC 32709K->15843K(259264K), 0.1554470 secs]
613.281: [Full GC 25096K->15932K(259264K), 0.1500100 secs]
618.982: [Full GC 35727K->16060K(259264K), 0.1558180 secs]
625.228: [Full GC 39090K->15677K(259264K), 0.1778470 secs]
638.611: [GC 39037K->15885K(259264K), 0.0034330 secs]
639.430: [Full GC 22116K->15866K(259264K), 0.1508080 secs]
646.904: [Full GC 26171K->16062K(259264K), 0.1532020 secs]
652.457: [Full GC 25748K->16156K(259264K), 0.1512670 secs]
658.609: [GC 39516K->16367K(259264K), 0.0032440 secs]
660.209: [Full GC 21359K->15677K(259264K), 0.1657590 secs]
664.911: [Full GC 34660K->15809K(259264K), 0.1562110 secs]
670.953: [Full GC 33108K->15937K(259264K), 0.1571950 secs]
673.849: [Full GC 29438K->16016K(259264K), 0.1531250 secs]
680.074: [GC 39376K->16523K(259264K), 0.0060770 secs]
680.279: [Full GC 26022K->15968K(259264K), 0.1805950 secs]
686.274: [Full GC 39141K->16092K(259264K), 0.1616190 secs]
688.844: [Full GC 36586K->16180K(259264K), 0.1567480 secs]
693.700: [Full GC 35574K->16344K(259264K), 0.1574960 secs]
700.598: [GC 39704K->16637K(259264K), 0.0035300 secs]
700.624: [Full GC 18174K->15872K(259264K), 0.1651170 secs]
703.509: [Full GC 34099K->16082K(259264K), 0.1573090 secs]
707.642: [GC 39442K->16171K(259264K), 0.0025780 secs]
709.815: [Full GC 28634K->16206K(259264K), 0.1534170 secs]
716.272: [Full GC 36047K->16381K(259264K), 0.1587900 secs]
723.495: [Full GC 39059K->16219K(259264K), 0.1683900 secs]
728.392: [GC 39577K->16618K(259264K), 0.0040680 secs]
728.415: [Full GC 18013K->16400K(259264K), 0.1536650 secs]
731.039: [Full GC 34082K->16531K(259264K), 0.1571980 secs]
737.472: [Full GC 32417K->16713K(259264K), 0.1577520 secs]
742.717: [Full GC 37469K->16111K(259264K), 0.1606780 secs]
744.274: [GC 39471K->16290K(259264K), 0.0033230 secs]
744.613: [Full GC 21102K->16265K(259264K), 0.1536350 secs]
748.395: [GC 39621K->16436K(259264K), 0.0031140 secs]
748.677: [Full GC 25242K->16359K(259264K), 0.1576130 secs]
750.854: [Full GC 31336K->16451K(259264K), 0.1585730 secs]
756.051: [Full GC 36466K->16119K(259264K), 0.1612460 secs]
759.115: [GC 39479K->16346K(259264K), 0.0028810 secs]
760.093: [Full GC 21902K->16228K(259264K), 0.1520320 secs]
763.760: [GC 39582K->16700K(259264K), 0.0059930 secs]
764.034: [Full GC 22526K->16387K(259264K), 0.1544760 secs]
768.679: [Full GC 32133K->16544K(259264K), 0.1591930 secs]
771.644: [Full GC 31230K->16325K(259264K), 0.1612140 secs]
776.770: [Full GC 38785K->16445K(259264K), 0.1620900 secs]
780.396: [Full GC 37938K->16896K(259264K), 0.1673300 secs]
782.776: [Full GC 30184K->17037K(259264K), 0.1590650 secs]
786.573: [GC 40397K->17228K(259264K), 0.0034880 secs]
786.731: [Full GC 19211K->16266K(259264K), 0.1549430 secs]
789.000: [GC 39619K->16361K(259264K), 0.0026020 secs]
789.269: [Full GC 19125K->16399K(259264K), 0.1513090 secs]
792.386: [Full GC 36010K->16508K(259264K), 0.1637400 secs]
795.102: [GC 39868K->16833K(259264K), 0.0040440 secs]
795.207: [Full GC 21389K->16739K(259264K), 0.1533440 secs]
799.324: [Full GC 23240K->16280K(259264K), 0.1577710 secs]
802.196: [GC 39639K->16518K(259264K), 0.0033770 secs]
802.399: [Full GC 22872K->16698K(259264K), 0.1572730 secs]
807.161: [GC 40058K->16776K(259264K), 0.0027580 secs]
809.900: [Full GC 36185K->16876K(259264K), 0.1607120 secs]
811.791: [Full GC 30282K->16978K(259264K), 0.1593370 secs]
813.563: [GC 40337K->17376K(259264K), 0.0064020 secs]
813.804: [Full GC 29057K->16982K(259264K), 0.1816130 secs]
815.297: [GC 40336K->17338K(259264K), 0.0039630 secs]
815.310: [Full GC 17806K->17082K(259264K), 0.1522910 secs]
819.516: [GC 40438K->17223K(259264K), 0.0028420 secs]
821.285: [Full GC 26923K->17272K(259264K), 0.1588350 secs]
823.559: [GC 40632K->17448K(259264K), 0.0031100 secs]
824.265: [Full GC 21492K->17462K(259264K), 0.1550870 secs]
825.397: [GC 40822K->17655K(259264K), 0.0031120 secs]
825.486: [Full GC 18871K->16337K(259264K), 0.1562730 secs]
829.469: [Full GC 38369K->16447K(259264K), 0.1650720 secs]
831.816: [GC 39807K->16601K(259264K), 0.0026710 secs]
831.827: [Full GC 17119K->16512K(259264K), 0.1522890 secs]
835.329: [GC 39872K->17080K(259264K), 0.0053700 secs]
835.465: [Full GC 23458K->16733K(259264K), 0.1581070 secs]
837.668: [GC 40093K->16935K(259264K), 0.0031290 secs]
838.251: [Full GC 20039K->16495K(259264K), 0.1564500 secs]
841.767: [Full GC 25895K->16613K(259264K), 0.1577470 secs]
844.476: [Full GC 35311K->16695K(259264K), 0.1628390 secs]
848.103: [GC 40044K->17069K(259264K), 0.0032710 secs]
848.628: [Full GC 22870K->16916K(259264K), 0.1580780 secs]
854.887: [Full GC 31905K->16323K(259264K), 0.1653390 secs]
857.228: [Full GC 36492K->16530K(259264K), 0.1634600 secs]
858.956: [GC 39890K->16815K(259264K), 0.0036330 secs]
862.023: [Full GC 21092K->16631K(259264K), 0.1564650 secs]
863.249: [Full GC 26164K->16781K(259264K), 0.1562600 secs]
865.711: [GC 40141K->17043K(259264K), 0.0031530 secs]
865.729: [Full GC 18180K->16457K(259264K), 0.1577410 secs]
869.627: [GC 39817K->16729K(259264K), 0.0033990 secs]
870.098: [Full GC 24966K->16659K(259264K), 0.1562460 secs]
872.350: [Full GC 31145K->16718K(259264K), 0.1604970 secs]
876.105: [Full GC 39279K->16941K(259264K), 0.1668260 secs]
880.207: [GC 40299K->17205K(259264K), 0.0034920 secs]
880.251: [Full GC 20652K->16517K(259264K), 0.1571090 secs]
883.114: [Full GC 37902K->16737K(259264K), 0.1646110 secs]
884.628: [Full GC 24661K->16849K(259264K), 0.1560830 secs]
888.022: [GC 40203K->17459K(259264K), 0.0051950 secs]
889.142: [Full GC 22380K->17051K(259264K), 0.1583020 secs]
891.554: [GC 40411K->17208K(259264K), 0.0027960 secs]
891.582: [Full GC 18063K->16781K(259264K), 0.1585470 secs]
892.405: [Full GC 29120K->17053K(259264K), 0.1622140 secs]
894.017: [GC 40406K->17464K(259264K), 0.0045690 secs]
895.447: [Full GC 31179K->17223K(259264K), 0.1628010 secs]
897.067: [Full GC 38729K->17329K(259264K), 0.1647360 secs]
900.396: [GC 40689K->17720K(259264K), 0.0044380 secs]
900.441: [Full GC 20648K->16903K(259264K), 0.1598090 secs]
902.678: [Full GC 35946K->17128K(259264K), 0.1663350 secs]
905.853: [GC 40488K->17532K(259264K), 0.0064380 secs]
905.891: [Full GC 19672K->17499K(259264K), 0.1621960 secs]
907.750: [GC 40847K->17670K(259264K), 0.0030520 secs]
908.460: [Full GC 20024K->17620K(259264K), 0.1565920 secs]
910.624: [GC 40980K->17765K(259264K), 0.0030090 secs]
910.671: [Full GC 18684K->16921K(259264K), 0.1605090 secs]
912.509: [Full GC 29066K->17017K(259264K), 0.1614450 secs]
913.757: [GC 40377K->17483K(259264K), 0.0047620 secs]
914.763: [Full GC 25902K->17141K(259264K), 0.1608170 secs]
917.689: [GC 40501K->17647K(259264K), 0.0049530 secs]
918.806: [Full GC 28871K->17294K(259264K), 0.1601960 secs]
921.558: [GC 40654K->17457K(259264K), 0.0029970 secs]
922.333: [Full GC 30464K->16925K(259264K), 0.1662820 secs]
923.373: [GC 40285K->17159K(259264K), 0.0042550 secs]
923.555: [Full GC 24496K->17082K(259264K), 0.1599500 secs]
927.044: [Full GC 37046K->17226K(259264K), 0.1683760 secs]
929.061: [GC 40586K->17346K(259264K), 0.0026490 secs]
929.162: [Full GC 21815K->17310K(259264K), 0.1590250 secs]
931.978: [GC 40670K->17413K(259264K), 0.0024780 secs]
932.513: [Full GC 23342K->16981K(259264K), 0.1626270 secs]
935.043: [GC 40341K->17151K(259264K), 0.0028210 secs]
935.520: [Full GC 29674K->17213K(259264K), 0.1660230 secs]
937.492: [GC 40573K->17558K(259264K), 0.0039620 secs]
937.670: [Full GC 23593K->17320K(259264K), 0.1597560 secs]
938.607: [GC 40680K->17648K(259264K), 0.0045610 secs]
939.678: [Full GC 33877K->17515K(259264K), 0.1648540 secs]
942.806: [GC 40869K->18021K(259264K), 0.0051340 secs]
944.254: [Full GC 35743K->17147K(259264K), 0.1719980 secs]
945.155: [Full GC 36250K->17530K(259264K), 0.1705550 secs]
946.222: [Full GC 34120K->17623K(259264K), 0.1649620 secs]
949.645: [Full GC 30572K->17807K(259264K), 0.1649170 secs]
952.442: [GC 41163K->17964K(259264K), 0.0030280 secs]
952.566: [Full GC 20289K->16895K(259264K), 0.1610340 secs]
954.853: [Full GC 28279K->17090K(259264K), 0.1638610 secs]
957.884: [GC 40445K->17584K(259264K), 0.0047550 secs]
958.667: [Full GC 32363K->17427K(259264K), 0.1661990 secs]
959.881: [Full GC 33152K->17499K(259264K), 0.1664660 secs]
964.265: [Full GC 37131K->17078K(259264K), 0.1695560 secs]
967.544: [Full GC 39971K->17286K(259264K), 0.1698470 secs]
972.467: [GC 40645K->17716K(259264K), 0.0058330 secs]
972.573: [Full GC 19899K->17688K(259264K), 0.1596110 secs]
973.323: [GC 41048K->18078K(259264K), 0.0039180 secs]
973.767: [Full GC 30629K->18056K(259264K), 0.1642740 secs]
975.978: [Full GC 32502K->16772K(259264K), 0.1692030 secs]
977.636: [GC 40132K->17237K(259264K), 0.0055500 secs]
978.935: [Full GC 25669K->16985K(259264K), 0.1628640 secs]
980.311: [Full GC 36664K->17060K(259264K), 0.1661300 secs]
984.254: [GC 40420K->17283K(259264K), 0.0035880 secs]
984.947: [Full GC 28397K->17339K(259264K), 0.1645970 secs]
988.111: [Full GC 30208K->16821K(259264K), 0.1669820 secs]
991.456: [Full GC 24124K->16941K(259264K), 0.1607770 secs]
994.575: [GC 40301K->17145K(259264K), 0.0035460 secs]
995.050: [Full GC 26065K->17242K(259264K), 0.1658660 secs]
996.625: [Full GC 37922K->17434K(259264K), 0.1697800 secs]
999.246: [Full GC 31259K->17049K(259264K), 0.1676220 secs]
1001.492: [GC 40408K->17779K(259264K), 0.0078300 secs]
1001.859: [Full GC 34893K->17307K(259264K), 0.1669200 secs]
1004.393: [GC 40666K->17525K(259264K), 0.0030640 secs]
1004.425: [Full GC 20060K->17436K(259264K), 0.1593370 secs]
1007.645: [GC 40794K->17669K(259264K), 0.0030540 secs]
1008.124: [Full GC 30847K->17795K(259264K), 0.1688060 secs]
1009.680: [Full GC 27073K->17588K(259264K), 0.1798900 secs]
1011.538: [Full GC 30414K->17677K(259264K), 0.1661910 secs]
1016.696: [GC 41037K->17878K(259264K), 0.0043140 secs]
1017.675: [GC 41238K->18305K(259264K), 0.0076230 secs]
1017.697: [Full GC 18965K->17980K(259264K), 0.1633270 secs]
1018.701: [Full GC 40089K->18034K(259264K), 0.1699260 secs]
1022.387: [Full GC 40085K->17215K(259264K), 0.1718460 secs]
1024.329: [GC 40575K->17390K(259264K), 0.0033200 secs]
1025.327: [Full GC 32127K->17405K(259264K), 0.1646980 secs]
1027.948: [GC 40765K->18028K(259264K), 0.0072570 secs]
1028.257: [Full GC 33726K->17576K(259264K), 0.1646440 secs]
1029.759: [Full GC 35673K->17688K(259264K), 0.1722710 secs]
1032.229: [Full GC 29552K->17224K(259264K), 0.1670930 secs]
1036.764: [GC 40584K->17488K(259264K), 0.0044870 secs]
1037.789: [Full GC 23532K->17375K(259264K), 0.1604060 secs]
1040.193: [Full GC 40682K->17543K(259264K), 0.1722250 secs]
1041.362: [GC 40902K->17948K(259264K), 0.0044240 secs]
1042.386: [Full GC 29926K->17651K(259264K), 0.1651240 secs]
1046.173: [GC 41011K->17786K(259264K), 0.0030940 secs]
1046.186: [Full GC 18169K->17442K(259264K), 0.1657440 secs]
1048.882: [GC 40802K->17670K(259264K), 0.0032420 secs]
1049.728: [Full GC 26921K->17623K(259264K), 0.1666840 secs]
1050.667: [Full GC 27281K->17714K(259264K), 0.1655080 secs]
1053.205: [Full GC 39795K->17784K(259264K), 0.1699730 secs]
1055.242: [Full GC 37892K->17524K(259264K), 0.1736060 secs]
1058.278: [GC 40877K->17783K(259264K), 0.0032240 secs]
1058.934: [Full GC 24636K->17670K(259264K), 0.1629560 secs]
1061.572: [Full GC 32462K->17738K(259264K), 0.1658050 secs]
1064.860: [GC 41090K->18049K(259264K), 0.0031520 secs]
1064.873: [Full GC 18402K->17913K(259264K), 0.1598100 secs]
1068.969: [GC 41272K->18129K(259264K), 0.0030650 secs]
1069.415: [Full GC 25714K->17421K(259264K), 0.1689390 secs]
1070.981: [Full GC 40072K->17529K(259264K), 0.1719780 secs]
1072.694: [Full GC 40298K->17684K(259264K), 0.1755570 secs]
1074.349: [Full GC 29692K->17760K(259264K), 0.1646700 secs]
1079.137: [GC 41120K->18001K(259264K), 0.0032570 secs]
1079.901: [Full GC 29267K->17912K(259264K), 0.1952200 secs]
1081.705: [GC 41272K->18459K(259264K), 0.0059700 secs]
1082.812: [Full GC 28652K->18115K(259264K), 0.1686030 secs]
1084.535: [GC 41475K->18286K(259264K), 0.0029690 secs]
1085.759: [Full GC 22825K->18304K(259264K), 0.1620300 secs]
1088.874: [GC 41664K->18557K(259264K), 0.0032180 secs]
1090.304: [Full GC 23507K->18428K(259264K), 0.1613190 secs]
1092.560: [GC 41787K->18731K(259264K), 0.0037290 secs]
1092.568: [Full GC 18918K->17280K(259264K), 0.1863890 secs]
1094.698: [Full GC 40048K->17487K(259264K), 0.1717440 secs]
1097.608: [GC 40847K->17639K(259264K), 0.0029460 secs]
1097.770: [Full GC 21453K->17546K(259264K), 0.1593820 secs]
1101.222: [Full GC 34584K->17699K(259264K), 0.1714350 secs]
1103.842: [Full GC 29518K->17398K(259264K), 0.1673060 secs]
1105.429: [Full GC 36543K->17480K(259264K), 0.1687430 secs]
1107.633: [GC 40839K->17863K(259264K), 0.0037960 secs]
1109.418: [Full GC 38489K->17844K(259264K), 0.1714760 secs]
1110.644: [GC 41201K->18176K(259264K), 0.0037780 secs]
1110.708: [Full GC 22032K->18031K(259264K), 0.1629450 secs]
1112.769: [Full GC 33242K->17641K(259264K), 0.1746310 secs]
1115.871: [GC 41001K->17913K(259264K), 0.0042400 secs]
1115.936: [Full GC 18849K->17868K(259264K), 0.1649840 secs]
1116.903: [GC 41228K->18158K(259264K), 0.0038590 secs]
1117.142: [Full GC 23635K->18147K(259264K), 0.1661090 secs]
1119.657: [Full GC 33873K->18237K(259264K), 0.1687550 secs]
1122.138: [GC 41597K->18843K(259264K), 0.0057360 secs]
1122.460: [Full GC 30191K->17352K(259264K), 0.1718040 secs]
1124.176: [GC 40711K->17534K(259264K), 0.0032200 secs]
1124.188: [Full GC 18088K->17408K(259264K), 0.1585710 secs]
1126.471: [GC 40768K->17610K(259264K), 0.0030090 secs]
1126.621: [Full GC 23207K->17585K(259264K), 0.1639700 secs]
1130.601: [GC 40945K->18032K(259264K), 0.0057690 secs]
1130.987: [Full GC 33251K->17715K(259264K), 0.1698070 secs]
1132.400: [GC 41075K->18200K(259264K), 0.0048990 secs]
1133.852: [Full GC 22412K->17396K(259264K), 0.1678410 secs]
1134.988: [GC 40756K->17811K(259264K), 0.0047240 secs]
1135.108: [Full GC 22610K->17538K(259264K), 0.1632820 secs]
1138.140: [Full GC 35484K->17677K(259264K), 0.1697280 secs]
1140.949: [GC 41037K->18028K(259264K), 0.0039610 secs]
1142.579: [Full GC 26182K->17886K(259264K), 0.1663820 secs]
1145.332: [Full GC 38186K->17413K(259264K), 0.1775910 secs]
1147.998: [Full GC 31086K->17542K(259264K), 0.1694310 secs]
1150.183: [GC 40902K->17680K(259264K), 0.0028430 secs]
1151.988: [Full GC 23320K->17714K(259264K), 0.1662670 secs]
1153.556: [GC 41074K->18019K(259264K), 0.0033240 secs]
1153.694: [Full GC 22297K->17819K(259264K), 0.1636210 secs]
1156.910: [Full GC 32491K->17555K(259264K), 0.1708090 secs]
1159.295: [GC 40915K->17925K(259264K), 0.0041940 secs]
1159.584: [Full GC 27356K->17749K(259264K), 0.1684860 secs]
1162.179: [Full GC 40840K->17842K(259264K), 0.1709320 secs]
1165.462: [Full GC 40836K->17998K(259264K), 0.1745900 secs]
1169.213: [Full GC 38228K->17387K(259264K), 0.1773150 secs]
1173.839: [Full GC 38730K->17553K(259264K), 0.1721990 secs]
1176.118: [Full GC 28517K->17724K(259264K), 0.1694920 secs]
1178.427: [GC 41084K->18236K(259264K), 0.0056840 secs]
1178.476: [Full GC 21916K->17907K(259264K), 0.1636330 secs]
1180.035: [Full GC 28804K->17629K(259264K), 0.1706580 secs]
1183.111: [GC 40989K->17821K(259264K), 0.0039230 secs]
1183.470: [Full GC 27647K->17770K(259264K), 0.1642930 secs]
1186.098: [Full GC 34782K->18020K(259264K), 0.1711540 secs]
1189.374: [GC 41380K->18148K(259264K), 0.0030680 secs]
1189.773: [Full GC 19108K->18108K(259264K), 0.1620400 secs]
1193.545: [GC 41468K->18264K(259264K), 0.0030810 secs]
1195.049: [Full GC 33109K->17520K(259264K), 0.1722670 secs]
1197.419: [Full GC 34615K->17775K(259264K), 0.1743520 secs]
1198.468: [Full GC 27126K->17819K(259264K), 0.1658660 secs]
1201.775: [GC 41179K->18064K(259264K), 0.0032670 secs]
1202.434: [Full GC 34303K->18285K(259264K), 0.1741190 secs]
1204.504: [GC 41645K->18591K(259264K), 0.0040820 secs]
1205.473: [Full GC 28617K->17816K(259264K), 0.1725460 secs]
1206.615: [Full GC 23644K->17914K(259264K), 0.1654130 secs]
1208.603: [GC 41274K->18294K(259264K), 0.0047020 secs]
1208.659: [Full GC 21617K->18046K(259264K), 0.1671710 secs]
1210.184: [Full GC 38308K->18107K(259264K), 0.1723240 secs]
1212.135: [Full GC 26647K->17955K(259264K), 0.1731150 secs]
1216.077: [GC 41314K->18170K(259264K), 0.0041080 secs]
1216.475: [Full GC 28069K->18058K(259264K), 0.1722190 secs]
1218.160: [GC 41418K->18256K(259264K), 0.0029660 secs]
1218.196: [Full GC 19422K->18244K(259264K), 0.1601460 secs]
1220.002: [Full GC 26298K->18354K(259264K), 0.1672780 secs]
1222.871: [Full GC 41007K->17486K(259264K), 0.1767970 secs]
1224.257: [Full GC 38459K->17581K(259264K), 0.1708260 secs]
1228.508: [Full GC 31027K->17678K(259264K), 0.1934270 secs]
1230.842: [GC 41038K->17846K(259264K), 0.0027980 secs]
1231.091: [Full GC 23773K->17876K(259264K), 0.1648090 secs]
1233.377: [GC 41235K->18030K(259264K), 0.0043450 secs]
1234.627: [Full GC 27018K->17623K(259264K), 0.1681140 secs]
1238.083: [GC 40983K->18145K(259264K), 0.0053580 secs]
1238.236: [Full GC 26915K->17828K(259264K), 0.1658790 secs]
1240.558: [Full GC 32151K->17956K(259264K), 0.1687010 secs]
1243.685: [GC 41310K->18474K(259264K), 0.0058920 secs]
1246.029: [Full GC 41795K->18533K(259264K), 0.1784250 secs]
1249.400: [GC 41893K->18739K(259264K), 0.0035550 secs]
1249.741: [Full GC 22503K->17989K(259264K), 0.1702740 secs]
1252.402: [GC 41347K->18176K(259264K), 0.0039630 secs]
1252.516: [Full GC 20445K->18258K(259264K), 0.1678890 secs]
1254.473: [Full GC 37435K->18439K(259264K), 0.1891770 secs]
1257.912: [GC 41797K->18658K(259264K), 0.0034350 secs]
1258.627: [Full GC 28099K->18792K(259264K), 0.1701140 secs]
1259.558: [GC 42151K->19185K(259264K), 0.0040460 secs]
1259.685: [Full GC 24326K->17830K(259264K), 0.1797960 secs]
1261.675: [Full GC 35858K->17895K(259264K), 0.1747070 secs]
1265.409: [GC 41253K->18235K(259264K), 0.0045390 secs]
1265.480: [Full GC 21386K->18167K(259264K), 0.1647190 secs]
1266.987: [GC 41527K->18518K(259264K), 0.0042120 secs]
1267.097: [Full GC 23121K->18225K(259264K), 0.1638840 secs]
1269.256: [GC 41579K->18556K(259264K), 0.0034600 secs]
1269.907: [Full GC 25021K->17589K(259264K), 0.1682260 secs]
1272.214: [Full GC 29448K->17641K(259264K), 0.1673120 secs]
1274.376: [Full GC 32613K->17885K(259264K), 0.1710000 secs]
1278.034: [GC 41245K->18309K(259264K), 0.0044890 secs]
1278.139: [Full GC 20559K->18359K(259264K), 0.1699630 secs]
1281.824: [GC 41719K->18836K(259264K), 0.0042590 secs]
1281.869: [Full GC 22173K->17938K(259264K), 0.1710780 secs]
1282.883: [Full GC 38905K->18085K(259264K), 0.1729570 secs]
1285.470: [Full GC 29364K->18221K(259264K), 0.1712110 secs]
1287.186: [GC 41579K->18392K(259264K), 0.0037710 secs]
1287.648: [Full GC 34833K->18379K(259264K), 0.1722590 secs]
1293.044: [Full GC 36896K->17895K(259264K), 0.1790080 secs]
1295.344: [Full GC 39122K->17997K(259264K), 0.1739800 secs]
1298.695: [GC 41356K->18180K(259264K), 0.0035400 secs]
1299.139: [Full GC 27101K->18151K(259264K), 0.1662500 secs]
1301.236: [Full GC 29897K->18243K(259264K), 0.1670530 secs]
1304.222: [GC 41599K->18690K(259264K), 0.0051650 secs]
1304.631: [Full GC 26785K->17570K(259264K), 0.1685990 secs]
1307.040: [Full GC 35984K->17736K(259264K), 0.1714940 secs]
1308.610: [Full GC 33194K->17867K(259264K), 0.1732130 secs]
1310.245: [GC 41227K->18348K(259264K), 0.0046460 secs]
1310.270: [Full GC 20079K->17997K(259264K), 0.1622390 secs]
1316.119: [Full GC 31797K->17701K(259264K), 0.1767490 secs]
1317.765: [GC 41061K->17911K(259264K), 0.0034320 secs]
1318.459: [Full GC 36597K->18147K(259264K), 0.1772120 secs]
1319.623: [Full GC 32165K->18210K(259264K), 0.1702940 secs]
1323.339: [GC 41570K->18394K(259264K), 0.0035930 secs]
1323.362: [Full GC 20003K->18302K(259264K), 0.1621850 secs]
1328.455: [GC 41662K->18528K(259264K), 0.0031090 secs]
1329.080: [Full GC 26141K->17601K(259264K), 0.1714570 secs]
1330.502: [GC 40960K->18190K(259264K), 0.0055370 secs]
1331.248: [Full GC 33207K->17743K(259264K), 0.1716600 secs]
1332.504: [Full GC 33325K->17919K(259264K), 0.1707440 secs]
1334.322: [Full GC 25962K->17964K(259264K), 0.1647600 secs]
1339.043: [GC 41324K->18445K(259264K), 0.0053560 secs]
1339.431: [Full GC 30802K->18036K(259264K), 0.1760700 secs]
1340.706: [GC 41396K->18435K(259264K), 0.0049790 secs]
1340.788: [Full GC 19653K->18362K(259264K), 0.1679480 secs]
1341.402: [Full GC 37930K->18541K(259264K), 0.1789520 secs]
1343.397: [Full GC 38599K->18598K(259264K), 0.1745700 secs]
1345.654: [Full GC 38131K->17863K(259264K), 0.1768640 secs]
1349.079: [Full GC 40810K->18034K(259264K), 0.1751080 secs]
1351.329: [GC 41394K->18181K(259264K), 0.0031310 secs]
1351.630: [Full GC 22737K->18131K(259264K), 0.1667750 secs]
1353.752: [GC 41491K->18415K(259264K), 0.0039180 secs]
1353.771: [Full GC 19663K->18329K(259264K), 0.1658580 secs]
1356.021: [Full GC 33020K->17962K(259264K), 0.1772410 secs]
1362.446: [GC 41322K->18319K(259264K), 0.0041650 secs]
1362.707: [Full GC 28140K->18280K(259264K), 0.1717800 secs]
1364.104: [GC 41640K->18440K(259264K), 0.0035700 secs]
1364.219: [Full GC 19931K->18444K(259264K), 0.1673940 secs]
1367.044: [Full GC 41175K->18638K(259264K), 0.1774620 secs]
1369.008: [GC 41998K->18904K(259264K), 0.0033770 secs]
1370.808: [Full GC 39500K->17736K(259264K), 0.1779480 secs]
1372.395: [Full GC 38579K->17798K(259264K), 0.1732010 secs]
1374.965: [GC 41158K->17977K(259264K), 0.0032530 secs]
1375.530: [Full GC 32640K->18465K(259264K), 0.1768610 secs]
1376.498: [Full GC 37663K->18530K(259264K), 0.1755930 secs]
1379.187: [Full GC 34360K->17772K(259264K), 0.1767890 secs]
1381.635: [GC 41132K->17916K(259264K), 0.0030470 secs]
1382.740: [Full GC 33087K->17979K(259264K), 0.1725710 secs]
1384.342: [Full GC 40704K->18127K(259264K), 0.1782130 secs]
1386.079: [Full GC 37351K->18238K(259264K), 0.1749410 secs]
1388.360: [Full GC 37386K->17696K(259264K), 0.1768570 secs]
1390.025: [Full GC 29469K->17756K(259264K), 0.1694570 secs]
1393.734: [GC 41112K->18057K(259264K), 0.0038490 secs]
1394.247: [Full GC 26711K->17971K(259264K), 0.1697510 secs]
1395.559: [GC 41331K->18421K(259264K), 0.0046160 secs]
1395.724: [Full GC 22935K->18369K(259264K), 0.1683440 secs]
1399.015: [GC 41729K->18557K(259264K), 0.0031830 secs]
1400.459: [Full GC 24074K->17934K(259264K), 0.1763530 secs]
1403.708: [GC 41285K->18399K(259264K), 0.0047150 secs]
1403.906: [Full GC 26160K->18149K(259264K), 0.1707510 secs]
1406.124: [GC 41509K->18387K(259264K), 0.0035380 secs]
1406.848: [Full GC 29898K->18662K(259264K), 0.1756120 secs]
1407.882: [Full GC 36353K->18762K(259264K), 0.1732850 secs]
1409.476: [Full GC 31392K->18111K(259264K), 0.1766410 secs]
1413.341: [GC 41471K->18259K(259264K), 0.0029240 secs]
1414.016: [Full GC 23700K->18347K(259264K), 0.1689310 secs]
1416.973: [GC 41707K->18621K(259264K), 0.0032220 secs]
1417.033: [Full GC 21370K->18493K(259264K), 0.1729750 secs]
1418.844: [Full GC 41535K->18652K(259264K), 0.1788500 secs]
1421.566: [Full GC 37085K->17599K(259264K), 0.1771590 secs]
1426.447: [Full GC 39674K->17772K(259264K), 0.1779320 secs]
1427.655: [Full GC 34052K->17910K(259264K), 0.1752830 secs]
1428.736: [Full GC 31329K->18038K(259264K), 0.1709880 secs]
1431.035: [GC 41398K->18234K(259264K), 0.0033650 secs]
1431.545: [Full GC 32607K->17774K(259264K), 0.1744760 secs]
1435.344: [Full GC 35392K->17901K(259264K), 0.1731200 secs]
1440.290: [Full GC 39635K->18103K(259264K), 0.1759120 secs]
1443.216: [GC 41463K->18459K(259264K), 0.0039860 secs]
1443.627: [Full GC 28455K->18606K(259264K), 0.1717400 secs]
1446.677: [Full GC 31845K->17807K(259264K), 0.1757170 secs]
1448.217: [Full GC 36029K->17929K(259264K), 0.1723040 secs]
1451.897: [Full GC 40425K->18068K(259264K), 0.1773810 secs]
1453.303: [GC 41428K->18399K(259264K), 0.0043310 secs]
1454.383: [GC 41747K->18891K(259264K), 0.0066130 secs]
1454.603: [Full GC 26649K->18470K(259264K), 0.1726960 secs]
1455.862: [GC 41830K->19071K(259264K), 0.0057860 secs]
1455.919: [Full GC 23860K->18080K(259264K), 0.1716680 secs]
1459.396: [GC 41440K->18551K(259264K), 0.0048670 secs]
1459.560: [Full GC 21678K->18433K(259264K), 0.1685140 secs]
1460.305: [Full GC 28004K->18540K(259264K), 0.1708560 secs]
1463.360: [GC 41898K->19157K(259264K), 0.0053660 secs]
1463.385: [Full GC 19875K->18963K(259264K), 0.1695990 secs]
1465.299: [GC 42322K->19230K(259264K), 0.0037680 secs]
1466.243: [Full GC 30800K->18146K(259264K), 0.2014600 secs]
1468.739: [GC 41506K->18435K(259264K), 0.0042590 secs]
1469.240: [Full GC 23481K->18360K(259264K), 0.1682010 secs]
1470.849: [Full GC 37140K->18509K(259264K), 0.1753980 secs]
1473.283: [Full GC 28643K->18566K(259264K), 0.1716950 secs]
1475.513: [GC 41926K->18655K(259264K), 0.0024490 secs]
1476.303: [Full GC 28013K->17893K(259264K), 0.1730760 secs]
1479.100: [GC 41253K->18106K(259264K), 0.0032820 secs]
1479.114: [Full GC 19042K->18011K(259264K), 0.1668360 secs]
1480.705: [GC 41371K->18216K(259264K), 0.0033410 secs]
1480.820: [Full GC 21912K->18126K(259264K), 0.1680140 secs]
1483.212: [GC 41483K->18657K(259264K), 0.0068210 secs]
1483.612: [Full GC 32191K->18531K(259264K), 0.1748200 secs]
1484.237: [Full GC 27101K->17945K(259264K), 0.1720220 secs]
1487.355: [GC 41304K->18052K(259264K), 0.0028180 secs]
1487.453: [Full GC 18350K->18034K(259264K), 0.1671100 secs]
1491.399: [Full GC 30457K->18216K(259264K), 0.1750190 secs]
1493.152: [GC 41576K->18373K(259264K), 0.0030600 secs]
1495.040: [Full GC 35834K->18553K(259264K), 0.1844910 secs]
1496.486: [Full GC 40056K->18404K(259264K), 0.1839830 secs]
1497.604: [Full GC 40636K->18576K(259264K), 0.1802690 secs]
1499.708: [Full GC 32806K->18699K(259264K), 0.1755440 secs]
1502.358: [GC 42056K->19017K(259264K), 0.0035950 secs]
1503.448: [Full GC 39416K->19186K(259264K), 0.1810510 secs]
1504.321: [GC 42546K->19502K(259264K), 0.0041760 secs]
1504.523: [Full GC 26135K->18075K(259264K), 0.1737100 secs]
1506.421: [Full GC 34630K->18190K(259264K), 0.1749040 secs]
1509.521: [Full GC 34218K->18280K(259264K), 0.1738500 secs]
1512.404: [Full GC 40123K->18419K(259264K), 0.1785160 secs]
1514.910: [GC 41779K->18978K(259264K), 0.0046400 secs]
1515.057: [Full GC 21217K->18346K(259264K), 0.1729520 secs]
1516.312: [Full GC 32009K->18445K(259264K), 0.1742600 secs]
1519.535: [GC 41800K->18681K(259264K), 0.0033170 secs]
1521.938: [Full GC 39950K->18817K(259264K), 0.1806540 secs]
1522.918: [Full GC 39996K->18896K(259264K), 0.1770260 secs]
1525.240: [Full GC 27208K->18087K(259264K), 0.1766390 secs]
1527.746: [GC 41446K->18283K(259264K), 0.0030650 secs]
1529.193: [Full GC 31590K->18230K(259264K), 0.1739110 secs]
1531.467: [GC 41590K->18408K(259264K), 0.0031390 secs]
1531.621: [Full GC 20536K->18343K(259264K), 0.1684640 secs]
1534.052: [Full GC 39614K->18673K(259264K), 0.1790600 secs]
1536.308: [Full GC 41947K->18277K(259264K), 0.1831870 secs]
1540.110: [GC 41634K->18676K(259264K), 0.0037740 secs]
1540.655: [Full GC 22982K->18554K(259264K), 0.1718110 secs]
1543.403: [Full GC 40455K->18762K(259264K), 0.1808010 secs]
1544.456: [GC 42122K->19049K(259264K), 0.0056720 secs]
1544.623: [Full GC 24100K->19040K(259264K), 0.1734450 secs]
1547.598: [GC 42399K->19313K(259264K), 0.0031750 secs]
1547.782: [Full GC 21803K->17896K(259264K), 0.1733430 secs]
1550.856: [Full GC 38776K->18049K(259264K), 0.1790000 secs]
1554.027: [Full GC 39925K->18209K(259264K), 0.1794380 secs]
1554.868: [Full GC 36385K->18297K(259264K), 0.1765220 secs]
1557.076: [GC 41657K->18481K(259264K), 0.0033910 secs]
1557.170: [Full GC 23085K->17844K(259264K), 0.1733090 secs]
1558.265: [Full GC 21638K->17878K(259264K), 0.1694620 secs]
1563.060: [GC 41237K->18097K(259264K), 0.0033500 secs]
1564.856: [Full GC 32663K->18154K(259264K), 0.1754150 secs]
1566.025: [GC 41510K->18340K(259264K), 0.0031060 secs]
1566.042: [Full GC 19331K->18242K(259264K), 0.1685920 secs]
1568.406: [GC 41602K->18499K(259264K), 0.0034100 secs]
1568.794: [Full GC 29429K->18048K(259264K), 0.1775530 secs]
1571.351: [Full GC 41276K->18129K(259264K), 0.1805000 secs]
1573.344: [Full GC 38881K->18195K(259264K), 0.1760390 secs]
1575.800: [Full GC 26060K->18243K(259264K), 0.1733030 secs]
1577.789: [Full GC 30691K->18180K(259264K), 0.1765060 secs]
1580.336: [GC 41540K->18408K(259264K), 0.0033330 secs]
1582.005: [Full GC 32348K->18433K(259264K), 0.1778330 secs]
1583.438: [GC 41793K->18751K(259264K), 0.0039520 secs]
1583.913: [Full GC 25360K->18656K(259264K), 0.1724900 secs]
1587.323: [Full GC 35278K->18824K(259264K), 0.1789120 secs]
1590.612: [GC 42183K->19194K(259264K), 0.0040080 secs]
1591.305: [Full GC 32714K->18075K(259264K), 0.1783630 secs]
1591.920: [Full GC 32296K->18141K(259264K), 0.1737070 secs]
1593.748: [

Memory leak on SunOne Web Server 6.1 on application reload

Hi!
I am pretty sure that i have found a memory management problem in
SunOne Web Server 6.1 .
It started with an OutOfMemory error we got under heavy load . After
some profiling with Jprofiler i didn't find any memory leaks in the
application.Even under heavy load (generated by myself) i can't find
anything ,more, i can't reproduce the error! The memory usage is
about 20Mb and does not go up .
However it is pretty simple to see the following behavior:
[1] Restart the server (to have a clear picture) and wait a little for
memory usage to stabilize.
[2] In the application dir. touch .reload or one of the classes:
The memory usage goes up by another 50Mb (huge amount of mem. taking
into account the fact that it used only 20Mb under any load befor).
Do this another time and another 20Mb gone etc..
The JProfiler marks the memory used by classes . And it can be
clearly seen the GC can't release most of it.
I AM sure this is not the application that takes all the memory.
Another hint : after making the server to reload application i can see
that the number of threads ON EVERY RELOAD is going up by ~10-20
threads .The # of threads goes lower over time but not the mem usage.
My system:
Sparc Solaris 9 ,Java 1.4.2_04-b05, Sun ONE Web Server 6.1SP5
Evgeny

my guess is that - because of '.reload' , web container tries to
recompile all the classes that you use within your web application and
hence the memory growth is spiking up.What do you mean by "tries to recompile"?The classes in
Web-inf are already compiled! And i have only ~5 jsp's .
(the most part of the applic. is a complicated business logic)
If you are talking about reloading them ,yes,that's the purpose of .reload,
isn't it? :).But it seems that container uses the memory for it's own
classes: the usage of memory for my classes don't really grow
that much (if at all) after reload (according to profiler)
Also the real problem is that the memory usage grows to much for
too long (neither seen it going down) and thus ends with OutOfMemory.
if you are seeing the memory growth to be flat in stress environment,
then I am not sure that why do you think that there is a memory leak ?There is no memory leak in stress environment.
There is memory leak while reloading the application.
It is a memory hog for sure (~20-30Mb for every reload).
Memory leak?It seems that way because i can't see memory usage go
down and after a lot of reloads OutOfMemory is thrown.
also, what is jvm heap that you use ? did you try jvm tune options like -
XX:+AggressiveHeap ?256Mb.I can set it bigger ,but how do i know that it will not just delay
the problem ?
Thanks for response.
Evgeny

Memory leak in ODBC Driver version 8.1.7.8?

We have a web application connected to an 8.1.7 database on a MS Windows 2000 SP 2 server.
We recently upgraded ODBC driver from 8.1.7.7 to 8.1.7.8 and found that we ran out of virtual memory.
On further investigations, a simple refresh of our summary web page (going to the database to select a small recordset - even when there are only 2 records with 6 small VARCHAR2 fields) causes the virtual memory usage to increase by approximately 1Mb each refresh.
The same refresh using driver 8.1.7.7 occasionally increases the VM usage by 4Kb!
Is there a memory leak in ODBC driver version 8.1.7.8?

Hello Thomas,
thanks for your tips, but they did not help. Activating Connection Polling did not change anything. And opening another connection did not help, either. I did it the following way:
Sub memtest2()
Dim conODBC As New ADODB.Connection
conODBC.ConnectionString = "Data Source='xxxx';User ID='xxx';Password='xxx'"
conODBC.Open
Dim Rs1 As Recordset, Rs2 As Recordset, DB1 As Database
Set DB1 = CurrentDb
Set Rs1 = DB1.OpenRecordset("select id from artikel")
Do While Not Rs1.EOF
    Set Rs2 = DB1.OpenRecordset("select * from artikel where id=" & Rs1("id"))
    'do something
    Rs2.Close
    Set Rs2 = Nothing
    Rs1.MoveNext
Loop
Rs1.Close
Set Rs1 = Nothing
DB1.Close
Set DB1 = Nothing
conODBC.Close
End Sub
Perhaps one of you has another tip how this can be done.
@Lukasz:
using a seperate ADODB.Connection works fine, but that does not solve the problem itself. At first I would have to rewrite much code and the second much bigger thing is that the memory leak occurs even when working with bound forms in MS Access. For example: I have one large form with many subforms on it. If i go from record to record on this form the memory usage is increasing dramatically fast and there is no way to influence what kind of connection MS Access is using for bound forms.
Regards
Thorstem

Memory Leak in Crystal Report XI

We are using Crystal Reports XI Licensed Developer version for web based application. The generated reports are getting accessed by multiple users from web interface. After continuos access of reports, at some point it reaches the maximum limit of Application pool and it stops the application.
From number of web forms, we found that crystal reports are not releasing systems memory and it keeps adding extra load on memory after a single report generation or there is memory leak. Below are the code snippets to initialize and dispose of report object.
a. Initializing a new report obj
protected ReportDocument _selectedRpt = new ReportDocument();
b. Disposing obj in page_unload event
/// <summary>
/// Page_Unload Event handler.
/// </summary>
/// <param name="sender">Sending control or event.</param>
/// <param name="e">Generic event arguments.</param>
protected void Page_Unload(object sender, EventArgs e)
_selectedRpt.Close();
_selectedRpt.Dispose();
Temporary Solution: For its temporary resolution, we are recycling application pool twice a day for smooth processing of reports, but recycling also destroying application session.
Please suggest a solution, which can help to run crystal reports correctly without any memory leak.

Helena, CR XI R2 is not supported in .NET 2008. See [this|https://wiki.sdn.sap.com/wiki/display/BOBJ/WhichCrystalReportsassemblyversionsaresupportedinwhichversionsofVisualStudio+.NET] wiki for more details.
Re. your unanswered post. Can you provide a link? I search for unanswered posts, but do not see one from you.
Remember that this is a community forum only, not support as such. If this is an important issue and you wish to discuss it with technical support, you can create a phone case here:
http://store.businessobjects.com/store/bobjamer/DisplayProductByTypePage&parentCategoryID=&categoryID=11522300
Ludek

Memory leak with UI automation

Hi,
I noticed there is memory leak with UI automation in my window 8.1.
I noticed there is solution for window 8
http://support.microsoft.com/kb/2885482
Is there any solution for window 8.1?
I really appreciate for any help.

Hi,
I'm sorry for didn't hear anything about this issue. I'll try to connect the writer of this KB, hope we can find some suggestion. If there is any progress about this problem, I would come back.
Roger Lu
TechNet Community Support

Tuxedo Memory Leak Issue (Tuxedo 8.1 - Windows Server 2003)

Hi
We are running tuxedo 8.1, 32 bit with patch level 258 in our windows server 2003 based production environment. We are currently facing an issue where the memory usage of machine slowly keeps on going higher and higher eventually resulting in “Memory Allocation Failure” to tuxedo servers. We then have to do a complete restart of tuxedo which stabilizes the system for other few days.
We have been analyzing the our source code in development/test environment using different tools like a customized Alzheimer tool and IBM purify but both tools reported no memory leaks. We then developed a test tuxedo server exposing a tuxedo service which simply allocates a memory to a response buffer and then returns the response buffer. I then configured tuxedo queue with same name “MEMTEST3” and configured a TMQForward server to call this “MEMTEST3” service every time a message is en-queued to the MEMTEST3 queue.
unsigned long _LIBENTRY ulTPAlloc(FBFR32 **ppc, long size)
unsigned long ulRes = MSG_SUCCESS_c;
ppc = (FBFR32 ) tpalloc("FML32", (char *) 0, size);
if (*ppc == (FBFR32 *) 0) {
vLogMessage(hGetLogHandle(), MSG_MEM_ALLOC_ERR_c, (char *) 0, (Event_t *) 0,
BM_NOSUPPRESS_c, size);
ulRes = MSG_MEM_ALLOC_ERR_c;
return (ulRes);
/*==============================================================================
Service MEMTEST2
==============================================================================*/
void MEMTEST3(TPSVCINFO *pRequest)
FBFR32 *pFmlResponse = NULL;
FBFR32 *pFml = NULL;
unsigned long ulRes = MSG_SUCCESS_c;
unsigned long ulActionCode = 0;
int iExitValue = 0;
long lTpurcode = 0;
FBFR32 *pFmlNULL = NULL;
userlog("Starting MEMTEST3 service.");
if (pRequest == NULL || pRequest->data == NULL)
vLogMessage(hGetLogHandle(), MSG_API_ARGS_ERR_c, NULL, NULL, BM_NOSUPPRESS_c);
ulRes = MSG_API_ARGS_ERR_c;
else
pFml = (FBFR32 *) pRequest->data;
userlog("MEMTEST3: GET THE MEM");
ulRes = ulTPAlloc(&pFmlResponse, 1024);
userlog("Ending MEMTEST3 service.");
tpreturn( iExitValue, lTpurcode, ( char * ) pFmlResponse , 0L, 0L );
While I was en-queuing the messages to the queue, I kept on monitoring the memory usage of the server hosting the service. What I observed was that I saw an initial hike in the usage of memory of the server followed by small jumps in memory increase. I kept on monitoring the server for a long time and the memory was never returned. What I suspect is that there is memory leak in tuxedo TMQforward process as it never released the memory allocated in the service.
Can anyone help how this situation can be avoided ?
Kind Regards,
Asim

Hi Todd,
Also as well as my previous question, I also found your reply to another user posting something similar at Re: Memory leaks in Tuxedo libraries
You mention that:
In general Tuxedo will free anything it allocates, although there are cases where memory is allocated and not freed because:
+1) it is one time or a fixed number of times allocations that will not continue to grow, and freeing up the memory just before exiting isn't of any benefit.+
+2) the memory is under Tuxedo's memory management functions where we manage our own look aside lists to provide better buffer allocation performance and again freeing these before process termination is of little benefit.+
Our code does only issue TPALLOC once and then a TPRETURN - could point (1) of your comment above also be something of concern to us, where we would observe a continuous growth of memory usage?
I know it may sound like a stupid question but do we need to run our code 20,000 times before memory gets freed?
Kind Regards,
Asim

Memory leak in OracleXMLSave?

I always get a Out of Memory : Java heap space
at oracle.xml.sql.dml.OracleXMLSave.saveNodeVal(OracleXMLSave.java:2854)
     at oracle.xml.sql.dml.OracleXMLSave.saveNodes(OracleXMLSave.java:2650)
     at oracle.xml.sql.dml.OracleXMLSave.saveXML(OracleXMLSave.java:2534)
     at oracle.xml.sql.dml.OracleXMLSave.insertXML(OracleXMLSave.java:1454)
after processing 3.5 million rows, no matter if this set was processed in rows of 10k or 100k or 1m.
each time the OracleXMLSave is nulled after each subset.
Usiing 10.2.0.2.0.
Is there a memory leak?
PS: What does cleanLobList() do?
Any advice?
Thanks

ok... I JProbed the app, and I got a 60% bulk of Object[], followed by Strings, and then XMLText and XMLNodes.
The Object[]s used grows but do not seem to be discarded when the data set shrinks. I see about 25% of these having much less references in my snapshot, while the rest have about the same number of references.
Is there going to be new Oracle XDK releases?

Memory leaks in MFC while using CDatabase::OpenEx()

Hi,
This question has been asked previously but the explanation was not in detail and i could never reach to the bottom of it.
I hope i can elaborate more on the problem statement and i can get a resolution/explanation from the experts here.
Consider the following two sample codes;
1.
int count = 200;
for (int i=0; i <count; ++i)
try
CDatabase *db = new CDatabase;
BOOL bRes = db->OpenEx(_T("DSN=MyData;UID=anon;PWD=pass"));
db->Close();
delete db;
db=NULL;
catch (CDBException* e)
e->Delete();
2.
CDatabase *db = new CDatabase;
int count = 200;
for (int i=0; i <count; ++i)
try
BOOL bRes = db->OpenEx(_T("DSN=MyData;UID=anon;PWD=pass"));
db->Close();
catch (CDBException* e)
e->Delete();
delete db;
db=NULL;
return 0;
delete db;
db=NULL;
The first sample code leaks a lot of memory and it can be easily observed from the task manager, the memory usage keeps on growing.
The second sample code does not leak any memory if i observe the memory usage from the task manager.
To find out the cause of the memory leak i ran the code through rational purify, both the codes are leaking memory according to rational purify. The first code leaks significantly more memory than the second one. The DLL pointed by rational purify are MFC
DLLs (inserting the screen shot below)
Is this a known issue with the MFC DLL or am i doing something wrong?
I have a server application where i have to create CDatabase object multiple times and i end up leaking a lot of memory over a period of time.
I can provide more information about this issue if required. Thanks in advance.

I am trying to reproduce this issue on my side, but it seem there is no memory leak in my simple sample. I use _CrtDumpMemoryLeaks() to test the memory leak.
https://msdn.microsoft.com/en-us/library/d41t22sb.aspx
If I comment this line: db->Close();
I can detect the memory leak at CDatabase
*db =
new CDatabase;
See the screenshot.
If follow your sample code, there is memory leak message in the output view pane.
#define CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#ifdef _DEBUG
#define new DEBUG_NEW
#endif.....int CMFCCdbMLTestApp::ExitInstance()
// TODO: Add your specialized code here and/or call the base class
_CrtDumpMemoryLeaks();
return CWinApp::ExitInstance();
May you can use some use tool like WinDbg tool to find more information about this issue.
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.

Memory Leak while using -Xrunhprof option in Linux OS

While using the follwing option in my application there is memory leak in JVM in Linux OS.
-Xrunhprof:heap=all,cpu=times,monitor=y,file=/home/gemini/dilip/www2.log,thread=yIs this a bug ??

Little lost here. Looks like you are facing memory leaks in Tuxedo 7.1 WS
client code when it talks with Tuxedo 6.x? Is this correct?
If so, try installing latest rolling patch for Tuxedo 7.1.
We recently fixed couple of memory leaks in interop area. One was related to
compression.
_shailesh
Scott Orshan <[email protected]> wrote in message
news:[email protected]..
If you are running with the latest patch, then report these problems to
Support, giving them sample code so that they can reproduce the problem.
Scott
Thomas Winter wrote:
Hi Scott,
as an additional information:
The guys at the server side changed something (their
formaly useing the old 6.3 libraries at server side)
and surprise... the client has no memory leak anymore.
But, if more than one thread at the same time use the atmi calls
there is still some memory consumption.
The workaround is to use a mutex object to make sure, that
only one thread use the atmi calls.
AFAIS Tuxedo has an Problem with Multithreading.
Thx
Thomas

CVI dll to read XML file causes memory leak

Hello,
I am facing a memory leak issue when I execute a dll created using CVI to read a XML file.
Each iteration of the step is taking around 200k of memory.
Short description of the code:
Basically I am using a function created in CVI to read from an XML file by tag which 2 attributes: command and the response;
int GetCmdAndRsp(char XML_File[MAX_STR_SIZE], char tag[MAX_STR_SIZE], char Command[MAX_STR_SIZE], char Response[MAX_STR_SIZE], char ErrorDescription[MAX_STR_SIZE])
inputs:
- XML_File_path;
- tagToFind;
ouputs:
- Command;
- Response;
- Error;
Example:
XMLFile:
<WriteParameter Command="0x9 %i %i %i %i %i" Response = "0x8 V %i %i %i %i"/>
Execution:
error = GetCmdAndRsp("c:\\temp\\ACS_Messages.xml" ,"WriteParameter", cmd, rsp, errStr)
output:
error = 0
cmd = "0x9 %i %i %i %i %i"
rsp = "0x8 V %i %i %i %i"
errStr = "Unkown Error"
Everything is working correctly but I have this memory leak issue. Why am I having such memory consumption?? Is it a TestStand or CVI issue??
Each iteration I am loading the file, reading the file and discarding the file.
Attached you can find the CVI project, a TestStand sequence to test (ReadXML_test2.seq) and an example of a XML file I am using.
Please help me here.
Thaks in advance.
Regards,
Pedro Moreira
Attachments:
ReadXML_Prj.zip ‏1826 KB

Pedro,
When a TestStand step executes, its result will be stored by TestStand which will be later used for generating reports or logging data into database.
You are looking at the memory (private bytes) when the sequence file has not finished execution. So, the memory you are looking at, includes the memory used by TestStand to store result of the step. The memory used for storing results will be de-allocated after finishing the sequence file execution.
Hence, we dont know if there is actual memory leak or not. You should look at the memory, before and after executing sequence file instead of looking in between execution.
Also, here are some pointers that will be helpful for checking memory leak in an application:
1. TestStand is based on COM and uses BSTR in many function. BSTR caches the memory and because of the behavior, sometime you might get false notion of having memory leak. Hence, you need to use SetOaNoCache function OR set the OANOCACHE=1 environment variable to disable caching.
2. Execute the sequence file atleast once before doing the actual memory leak test. The dry run will make sure all static variables are initialized before doing memory leak test.
3. Make sure that the state of system or application is same when considering the Private bytes. Ex: Lets say ReportViewControl is not visible before you start executing sequence file. Then you note down the private bytes and then execute the sequence file. After finishing execution, make sure you close the ReportViewControl and then note down the private bytes once again to check if memory is leaked or not.
4. If there exists memory leak as you specified, it is possible that the leak is either in TestStand, or in your code. Make sure that your code doesn't leak by creating a small standalone application (probably a console application) which calls your code.
Detecting memory leaks in CVI is better explained in
http://www.ni.com/white-paper/10785/en/
http://www.ni.com/white-paper/7959/en/
- Shashidhar

Finding Memory leaks in C using Visual Studio 2013

I am using Visual Studio 2013, and taking a course in C programming and we started
talking about memory bugs detaction, in particular memory leaks, and how to detect them using Valgrind on Linux.
I want to know if there is a way to detect such memory leaks using VS 2013. I tried searching online but it just leads to lots of articles and blogs and msdn posts and blogs with lots of words like dump files, and analyzing them, etc which is weird
because:
1) It sounds so complex, convoluted and unintuitive it is actually hard to comprehend it.
2) The main reason this is weird is due to the fact that VS is the most advanced IDE around and Microsoft spends so much money on in, yet from what I have read it seems that there is no simple way to use VS to detect memory leaks
- certainly no way that's as simple as Valgrind where I only have to compile the program and run the command valgrind -leaks-check=yes ProgramName
and it simply prints to me all location it thinks there is a memory leak and describes the error (like not freeing memory after allocating it with malloc hence having "dead" memory after the program finishes, or accessing memory that's out of
the array bounds)
So my question is how to use VS 2013 in order to achieve the same results and to find out First in high level if there are memory leaks in the program, and Second - to detect in a simple manner where those leaks are- preferably without involving dump files
(not that I know how to use them anyway in VS).

Hi MicrosoftLaw,
Thanks for your post.
Based on your issue, if you want to check if there are memory leaks in the C program from this VS2013. I suggest you could try to find Memory Leaks Using the CRT Library, for more information:
https://msdn.microsoft.com/en-us/library/x98tx3cf.aspx?f=255&MSPPError=-2147217396
In addition, I find a similar thread about this issue, please you refer the Dusty's suggestion to check this issue.
http://stackoverflow.com/questions/45627/how-do-you-detect-avoid-memory-leaks-in-your-unmanaged-code
I did some research about this issue, I found that the Visual Leak Detector extension tool is a free, robust, open-source memory leak detection system for Visual C++. So if possible, I suggest you could try to use the Visual Leak Detector extension
tool to find the memory leak for Visual C/ C++ program.
https://visualstudiogallery.msdn.microsoft.com/7c40a5d8-dd35-4019-a2af-cb1403f5939c
However, if you have any issue about how to use this Visual Leak Detector extension tool to find the memory leak for C program. I suggest you could directly to write a review to this REVIEW tab in Visual Leak Detector site.
Best Regards,
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.

Is there a memory leak in Aperture 3.5?

Similar Messages

Maybe you are looking for