Frequent hangs when manipulating the profile lock

VERIFIED DUPLICATE of bug 566208

Status

Core Graveyard
Profile: BackEnd
--
major
VERIFIED DUPLICATE of bug 566208
8 years ago
2 years ago

People

(Reporter: hsivonen, Unassigned)

Tracking

({hang})

Trunk
x86_64
Linux

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
Created attachment 461203 [details]
Stack trace

On recent (as of late July 2010) trunk, I've seen relatively common browser hangs with 
#0  __lll_lock_wait ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
#1  0x00007fa986ce160f in _L_lock_1172 () from /lib/libpthread.so.0
#2  0x00007fa986ce155a in __pthread_mutex_lock (mutex=0x7fa986fd5040)
    at pthread_mutex_lock.c:101
#3  0x0000000000407f53 in free ()
#4  0x00007fa98570d150 in nsProfileLock::Unlock() ()
   from /home/hsivonen/Projects/obj-opt/dist/bin/libxul.so
#5  0x00007fa98570d185 in nsProfileLock::RemovePidLockFiles() ()
on the top of the stack.

This typically happens when closing a tab. However, I don't have proper steps to reproduce. Try opening http://www.whatwg.org/specs/web-apps/current-work/ in a tab, closing the tab and repeating until the browser hangs.

Comment 1

8 years ago
You crashed inside the malloc lock and then the signal handler tried to allocate memory.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 566208

Updated

8 years ago
Status: RESOLVED → VERIFIED
(Assignee)

Updated

2 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.