Open
Bug 841198
Opened 11 years ago
Updated 2 years ago
Try to provide some debug aid for finding which connections are not closed.
Categories
(Toolkit :: Storage, defect, P5)
Tracking
()
NEW
People
(Reporter: espindola, Unassigned)
Details
Attachments
(1 file)
1.37 KB,
patch
|
Details | Diff | Splinter Review |
Every time I want to debug a connection not being closed I type something like the attached patch. Maybe there is already something better in the tree and we just have to document it, but if not, any ideas on what is the best way to include this (probably with an ifdef)?
Attachment #713680 -
Flags: feedback?(mak77)
Comment 1•11 years ago
|
||
We have a PR_LOG at PR_NOTICE level already, no? But maybe we could also add a function that could be called from gdb that dumps the contents of mConnections in a pretty fashion. Like how you can "call DumpJSStack()" to see the JS stack.
Reporter | ||
Comment 2•11 years ago
|
||
(In reply to Andrew Sutherland (:asuth) from comment #1) > We have a PR_LOG at PR_NOTICE level already, no? > > But maybe we could also add a function that could be called from gdb that > dumps the contents of mConnections in a pretty fashion. Like how you can > "call DumpJSStack()" to see the JS stack. Sure. The main problem is that you know that the connection at 0x12345678 is not being closed. Now you need to find out which connection is it. Unfortunately there is enough non determinism in firefox that it is unlikely the next run will allocate it to the same address, which is why my hack uses a map to assign an id. That makes it easy to create a conditional breakpoint that stop when that connections is created.
Comment 3•11 years ago
|
||
Ah, that makes sense. So you'd be happy if you could allocate the id, assign it to a member variable on the connection (seems cheaper than a map and potentially much easier to use in other conditional breakpoints), and have that output as part of the PR_LOG as well?
Reporter | ||
Comment 4•11 years ago
|
||
(In reply to Andrew Sutherland (:asuth) from comment #3) > Ah, that makes sense. So you'd be happy if you could allocate the id, > assign it to a member variable on the connection (seems cheaper than a map > and potentially much easier to use in other conditional breakpoints), and > have that output as part of the PR_LOG as well? That would work. We just have to make sure we don't include the ID on debug builds.
Reporter | ||
Comment 5•11 years ago
|
||
(In reply to Andrew Sutherland (:asuth) from comment #3) > Ah, that makes sense. So you'd be happy if you could allocate the id, > assign it to a member variable on the connection (seems cheaper than a map > and potentially much easier to use in other conditional breakpoints), and > have that output as part of the PR_LOG as well? That would work. We just have to make sure we don't include the ID on debug builds.
Comment 6•11 years ago
|
||
Comment on attachment 713680 [details] [diff] [review] hack Review of attachment 713680 [details] [diff] [review]: ----------------------------------------------------------------- I don't think map is thread-safe nor what's the mozilla take on its usage (for portability reasons), but looks like it's used in some crashreporter and media code. Btw, what asuth suggested makes more sense, I'm also not sure why we don't log the database name too, that would help, usually I have to make a script to parse the PRLog output and filter queries by database.
Attachment #713680 -
Flags: feedback?(mak77)
Updated•6 years ago
|
Assignee: respindola → nobody
Status: ASSIGNED → NEW
Priority: -- → P5
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•