Open Bug 841198 Opened 7 years ago Updated 2 years ago

Try to provide some debug aid for finding which connections are not closed.

Categories

(Toolkit :: Storage, defect, P5)

x86
macOS
defect

Tracking

()

People

(Reporter: espindola, Unassigned)

Details

Attachments

(1 file)

Attached patch hackSplinter 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)
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.
(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.
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?
(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.
(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 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)
Assignee: respindola → nobody
Status: ASSIGNED → NEW
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.