Closed Bug 13030 Opened 26 years ago Closed 26 years ago

Purify dead in the water

Categories

(SeaMonkey :: Build Config, defect, P1)

Product:
SeaMonkey
Component:
Build Config
Platform:
Sun
Solaris
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: bruce, Assigned: ftang)

References

Details

Attachments

(1 file)

patch that fixes the freebsd crash (and possibly the purify problem as well)
2.67 KB, patch
Details | Diff | Splinter Review
For me, Purify is finding an error on startup everytime that doesn't exist when running a non-Purified binary. This is probably in part due to the lack of fully PIC DSOs which Purify warns about. Even though it was warning, I was able to still run up until 2-3 days ago. I'm not sure where to attack this, except to work at getting the build system back to where it was when DSOs were fully PIC.
This is the stack trace for what is killing it: **** Purify instrumented ./apprunner.pure (pid 5954) **** MSE: Memory segment error: * This is occurring while in: PL_strcmp [strcmp.c:27] NSRegisterSelf [nsUCvLatinDll.cpp:914] nsNativeComponentLoader::SelfRegisterDll(nsDll*,const char*) [nsNativeComponentLoader.cpp:470] nsNativeComponentLoader::AutoRegisterComponent(int,nsIFileSpec*,int*) [nsNativeComponentLoader.cpp:709] nsNativeComponentLoader::RegisterComponentsInDir(int,nsIFileSpec*) [nsNativeComponentLoader.cpp:302] nsNativeComponentLoader::AutoRegisterComponents(int,nsIFileSpec*) [nsNativeComponentLoader.cpp:246] nsComponentManagerImpl::AutoRegister(nsIComponentManager::RegistrationTime,nsIFi leSpec*) [nsComponentManager.cpp:1795] nsComponentManager::AutoRegister(nsIComponentManager::RegistrationTime,nsIFileSp ec*) [nsRepository.cpp:197] NS_AutoregisterComponents() [nsSetupRegistry.cpp:89] NS_SetupRegistry_1 [nsSetupRegistry.cpp:109] main1(int,char**) [nsAppRunner.cpp:752] main [nsAppRunner.cpp:852] _start [crt1.o] * Accessing a memory range that crosses a memory segment boundary. Addressing 0xfffc0000 for 1 byte ending at 0xfffc0001, which is neither in the heap nor the main stack. At the point where it is bombing, it was looking at factory data in nsUCvLatinDll.cpp ... if I use JIT debugging with purify and try to look at that data, I see things just fine. Can anyone else duplicate this?
adding shaver and dp to cc
adding shaver and dp to cc
anyone have any progress on this? it is blocking ramiro as well (he's confirmed it on worms). there is no purify work happening on unix.
Priority: P3 → P1
The behaviour we seen in bug #13398 might be a compiler bug, but I really don't know how to debug this one. We can't reproduce it without purify and JIT debugging shows us that purify is on crack. Maybe we have to call Rational support?
toshok is seeing a failure in loading this DSO on FreeBSD without Purify. cc'ing him as it might be related?
Thanks to a lot of hard work by toshok tonight, some progress has been made. The stack trace above is not the crash that is killing us. It appears that there is some sort of evil stack disease and that stack trace is just a symptom. Now assuming that this is an artifact of the rewrite of the component manager. Ugh.
it does indeed fix the purify problem.
ftang, can you review and lets get this muther checked in.
Assignee: briano → ftang
Toshok, awesome. Can you summarize the problem. It looks like a static data initialization in a component dll. Reassigning to ftang for fix checkin.
Status: NEW → ASSIGNED
wait for toshok to try my new check in. (not his patch)
Target Milestone: M11
Your new checkin kills Purify again, so it probably kills FreeBSD (toshok's platform) as well.
Can someone explain to me what really happen here ? How can I reproduce it without using a FreeBSD build ? Can someone try rev 1.40. If the problem is still there, try to uncomment the // #define DEBUG_PROGID in the begining of the line and see what is the output.
I will look into this later today or this evening.
bug 13154 could realted to this. add braino@netscape.com to the CC.See my latest comment there.
We have some progress on 13154 for FreeBSD, please take a look at that. But I don't think it will complete solve this Purify problem , right ? Is this only happen on Sun ? Or it also a problem on Window Purify ? If it only happen on Sun, could bruce do a nm libucvlatin.so|egrep g_FactoryData for me ?
Target Milestone: M11 → M12
Move to M12.
Whoa there. Why did this get moved to M12? This is a CRITICAL issue for us. What other bugs do you have that are also P1/blocker and would therefore contend for time with this one?
This is blocker for Solaris, not Linux. Therefore, not M11/Beta1 blocker. I don't build on Solaris. I have no way to fix it without people work with me on Solaris. No one try my changes since 9/13. And I don't think I can do anything to it without help from people building solaris. I know this is a Solaris blocker, but not M11/Beta blocker, right ? Solaris build is not part of Beta Criteria. [Don't get me wrong. I love to help. Maybe this bug should have a new owner?] You are welcome move it back to M11 if 1) you build Solaris and 2) you could reproduce the problem, and 3) you can provide me feedback in hourly basis. Is this reasonable ?
Target Milestone: M12 → M11
Hold on there! Solaris is the only Unix platform that runs Purify, and without Purify we have memory leaks which we *know* are killing us on LINUX. You might be able to put off a minor Solaris-only bug, but not something that kills all Purify work! This is a BLOCKER.
As I said, anyone are more than welcome to move this bug back to M11 as long as s/he can do the 3 thing I mention. Otherwise, we are simply fooling ourself that we will fix this for M11. M11 freeze is 25:35 hours away and I have no way to work on this unless people can debug this remote with me. This is not a trival issue. The compiler generate some code that does not work for Purify. I have no way to fix this from my side. Maybe I should pass this to someone else.
dveditz move this back to M11. So I assume 1) he have Solaris build, 2) he can reproduce this problem, 3) he can work with me in hourly basis. Dan, call me anytime (24 hours stand by) Find my phone number from phone book.
squishing memory leaks is high on the list of beta criteria. if this is blocking leak analysis let figure out a way to get it fixed.
We _have_ a fix for this, Frank. This bug could be completely resolved if we just checked in toshok's patch. Why are you reluctant to do that? Does the patch break some other system? It works fine on my Linux box.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
1. Toshok tell me not to check in his patch. He say that patch is not good. 2. I call bruce, and he said the build he pull in this morning 1.41 do not have the problem any more. I guess the problem is same as 13451 and have been fixed several days. The only reason this bug is still OPEN is because no one verify that for me. (Bruce is pretty busy in this serveral days.) After talk to brunce, we decided to mark this FIXED and he say he will mark it as VERIFIED tonight. Plesae do not reopen this bug or change the Target Mileston unless YOU can reprduce this problem. I believe this no longer a blocker after talk to bruce. A lot of "Much ado about nothing" comment of this bug from 9/20-9/21. Problem have been fix. Simply no one can confirm that in that time. Guess everybody is happy now.....
Status: RESOLVED → VERIFIED
I'll happily verify that this was fixed for me. Thanks!
*cheers*
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: