Closed Bug 414451 Opened 12 years ago Closed Last year
Venkman crashs on profiling after clearing profile data [@ _call
Assignee: nobody → rginda
Product: Firefox → Other Applications
QA Contact: extension.manager → venkman
Product: Other Applications → Firefox
Version: unspecified → 2.0 Branch
Product: Firefox → Other Applications
Version: 2.0 Branch → 1.8 Branch
Summary: Venkman crashs on profiling after clearing profile data → Venkman crashs on profiling after clearing profile data [@ _callHook]
So unfortunately, nothing is going to happen to this bug unless you can get me working steps to reproduce, preferably on trunk. I just don't have the time to randomly surf around waiting for my build to magically crash. I haven't seen this myself, and while I'd love to do something about it, I can't until you give me more information. Sorry!
Severity: critical → normal
I tried to reproduce the bug on Windows XP SP2 with Firefox 2.0.11 and Vekman 0.9.87.2, but it never crashed. The bug is specific to Linux or it's harder to reproduce it on Windows. So, bug workaround: use Windows instead of Linux ;-)
jsd_ClearAllProfileData seems /relatively/ sound. it calls lock scripts. 290 jsd_ClearAllProfileData(JSDContext* jsdc) 294 JSD_LOCK_SCRIPTS(jsdc); 298 jsd_ClearScriptProfileData(jsdc, current); 302 JSD_UNLOCK_SCRIPTS(jsdc); however, the code to get script profile data doesn't seem to call lock scripts. 140 JSD_UNLOCK_SCRIPTS(jsdc); 147 pdata = jsd_GetScriptProfileData (jsdc, jsdscript); 290 jsd_GetScriptProfileData(JSDContext* jsdc, JSDScript *script) 292 if (!script->profileData) 293 script->profileData = (JSDProfileData*)calloc(1, sizeof(JSDProfileData)); 295 return script->profileData; i think this: 147 pdata = jsd_GetScriptProfileData (jsdc, jsdscript); needs to be done while holding a lock. while we're at it, 238 JSD_ClearScriptProfileData(JSDContext* jsdc, JSDScript *script) 241 jsd_ClearScriptProfileData(jsdc, script); that's a public function which isn't holding a lock. 116 JSD_ClearAllProfileData(JSDContext *jsdc) 119 jsd_ClearAllProfileData(jsdc); this is the public function exercised by venkman (see below). ClearProfileData * js/jsd/jsd_xpc.cpp, line 1360 (View change log or Blame annotations) * js/jsd/jsd_xpc.cpp, line 2740 (View change log or Blame annotations) Defined as a function prototype in: * js/jsd/idl/jsdIDebuggerService.idl, line 236 (View change log or Blame annotations) * js/jsd/idl/jsdIDebuggerService.idl, line 790 (View change log or Blame annotations) Referenced (in 2 files total) in: * js/jsd/jsd_xpc.cpp (View change log or Blame annotations) o line 1361 o line 2741 * extensions/venkman/resources/content/venkman-commands.js (View change log or Blame annotations) o line 621 o line 625 o line 629 summary: _callHook needs to JSD_LOCK_SCRIPTS for its call to jsd_GetScriptProfileData JSD_ClearScriptProfileData needs to JSD_LOCK_SCRIPTS for its call to jsd_ClearScriptProfileData.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Like this? I'll run a tryserver build with this patch and post URLs for the reporter to try when I have them.
Assignee: rginda → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Attachment #302321 - Flags: review?(timeless)
Egh, looks like the tryserver builds aren't going to work out until tomorrow night. Sorry! In the meantime you can build on your own, of course, if you feel up to it. :-)
Comment on attachment 302321 [details] [diff] [review] Possible patch yeah, this is what i had in mind, but when i looked at the code, i found that it's not really sufficient to make jsd not broken. it might be sufficient to fix this crash. I have a much bigger (yet unfortunately incomplete changeset) on my computer.
Attachment #302321 - Flags: review?(timeless) → review+
(In reply to comment #7) > (From update of attachment 302321 [details] [diff] [review]) > yeah, this is what i had in mind, but when i looked at the code, i found that > it's not really sufficient to make jsd not broken. it might be sufficient to > fix this crash. > > I have a much bigger (yet unfortunately incomplete changeset) on my computer. > OK, so should I still check this in, or obsolete and wait for yours?
(In reply to comment #6) > Egh, looks like the tryserver builds aren't going to work out until tomorrow > night. Sorry! In the meantime you can build on your own, of course, if you feel > up to it. :-) > TryServer builds should now appear in a couple of hours in https://build.mozilla.org/tryserver-builds/?C=M;O=D (in a subdir which has my committer ID (email@example.com) in it). I'd give a direct link, but they're not there yet and I'm going to catch some sleep, so. :-)
Reassigning per previous comments.
Assignee: gijskruitbosch+bugs → timeless
Status: ASSIGNED → NEW
I'm not sure what the state is here, but does not seem to involve Firebug, removing priority
Whiteboard: [firebug-p2] →
The state is that assigning to timeless without also nagging him on IRC every time he seems to be goofing off when he could be patching jsd is the same as not assigning.
Target Milestone: --- → Future
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.