-
Notifications
You must be signed in to change notification settings - Fork 29.6k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
lib: don't penalize setInterval() common case
The common case is where setInterval() is called with two arguments, the callback and the timeout. Specifying optional arguments in the parameter list forces common case calls to go through an arguments adaptor stack frame. PR-URL: #1221 Reviewed-By: Trevor Norris <[email protected]>
- Loading branch information
1 parent
31da975
commit 33fea6e
Showing
1 changed file
with
28 additions
and
30 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
33fea6e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bnoordhuis this patch gives me an error when #1152 is applied on it:
33fea6e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does the backtrace look like in gdb or lldb?
33fea6e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
./configure --debug --gdb
Didn't change anything, I'll try to get gdb/lldb configured properly tomorrow.33fea6e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using https://github.com/thlorenz/lldb-jbt
Still no stack frames, but error seems expanded?
33fea6e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, using lldb-jbt properly (i think) now:
EDIT: Also got
bt
for this: EDIT2: usingjbt
:33fea6e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, something else? (by running the above again..)
(this time with
bt
after) EDIT: withjbt
:33fea6e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That assert implies that the timer callback is not a function.
If that segfaults, it suggests a wild pointer.
I speculate we're looking at memory corruption due to bad lifecycle management of unref'd timers. Possible causes: deleting the TimerWrap before the uv_timer_t handle is closed, closing the uv_timer_t when the persistent handle is not dead yet, etc.
33fea6e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A third?
33fea6e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, so that's almost certainly some kind of memory corruption. :-)
This commit can't have introduced it but maybe it exposes it.
33fea6e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this exposes mem corruption in #1152's patch then?
33fea6e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(i.e. this stack if from this commit + those patches)
33fea6e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I had to guess, I'd say the call to
this.owner.close()
in #1152 has something to do with it.33fea6e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I suspected as much.
cc @trevnorris
33fea6e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reason for calling
close()
is to make sure the destructor is called. Ah suck, though now thinking about it if there are multiple JS timers linked to the same C++TimerWrap
class then all hell could break loose. So.close()
should only be run if the calling timer is the last timer attached to that class instance.Ref: 0d05123