[from kipp@netscape.com] I did an experiment today. First I run a viewer build under gdb on my (now quite fat :-) linux box: [1] 24822 p1 S 0:18 8215 974 161153 160660 xx 62.4 gdb viewer core Yes maam, that's 161,153 thousand Kbytes of mem-oh-rey. Yikes! Then I went into nsRepository and disabled the loading of dll's for auto-registration: [2] 24876 p1 S 0:10 764 974 109825 109544 xx 42.6 gdb viewer core Not bad, a 61 thousand Kbytes of mem-oh-rey improvement. Still yikes! Finally, I tried running the program from /tmp and lo and behold: [3] 24891 p1 S 0:08 259 974 87285 87080 xx 33.8 gdb /home/kipp/r/trunk/mozilla/dist/bin/viewer core Now, you may ask, whats the difference. Well, during gdb's (4.17.0.4) startup it lists out the libraries that its reading symbols from. In the first case [1], that list included copies of every .so file in the bin directory. The second case [2] had a shorter list because we were no longer running dp's auto-registration code. The 3rd case was even shorter because there are no .so files in /tmp. So, we have a bug folks and it needs to be fixed ASAP so that the normal execution doesn't have alot of redundant dll's being loaded into memory. What I believe the problem to be is that the repository is loading duplicate .so files because it isn't normalizing the path names. The unix dl* routines aren't smart enough to realize that the "./" in the middle of the path name isn't relevant. here is some sample gdb output of the duplicate names: Reading symbols from /home/kipp/r/trunk/mozilla/dist/bin/./libjs.so...done. Reading symbols from /home/kipp/r/trunk/mozilla/dist/bin/./libmozdbm.so...done. Reading symbols from /home/kipp/r/trunk/mozilla/dist/bin/./libreg.so...done. Reading symbols from /home/kipp/r/trunk/mozilla/dist/bin/./libxpcom.so...done. Reading symbols from /home/kipp/r/trunk/mozilla/dist/bin/./libmozutil.so...done. Reading symbols from /home/kipp/r/trunk/mozilla/dist/bin/./libraptorhtml.so...done.

changing priority to P1 since so many folks are affected by this. Also adding akk, donm, sar, chofmann to the cc list.

Just to note we have a similiar problem on the Mac and are researching how to best fix the problem (as the quick fixes weren't).

This problem is fixed on linux. New rpms of gcc need to get installed. Now it is the MACs turn. Robert is incharge of this bug.

h-208-12-39-147 # grep 2245e573-9464-11d2-9b8b-00805f8a16d9 out |grep Register 1024[8050d00]: nsRepository: RegisterFactory({2245e573-9464-11d2-9b8b-00805f8a16d9}, ./libraptorbase.so), replace = 1, persist = 1. 1024[8050d00]: nsRepository: RegisterFactory({2245e573-9464-11d2-9b8b-00805f8a16d9}, ./libjsdom.so), replace = 1, persist = 1. 1024[8050d00]: nsRepository: RegisterFactory({2245e573-9464-11d2-9b8b-00805f8a16d9}, ./libwidgetgtk.so), replace = 1, persist = 1. 1024[8050d00]: nsRepository: RegisterFactory({2245e573-9464-11d2-9b8b-00805f8a16d9}, ./libraptorhtml.so), replace = 1, persist = 1. 1024[8050d00]: nsRepository: RegisterFactory({2245e573-9464-11d2-9b8b-00805f8a16d9}, libraptorbase.so), replace = 0, persist = 0.

Fixed. Auto-registering components now go into a "components" directory.

based on developer input, marking verified