Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pipeline exiting causing segfault again. #965

Closed
tikue opened this issue Sep 21, 2013 · 4 comments
Closed

Pipeline exiting causing segfault again. #965

tikue opened this issue Sep 21, 2013 · 4 comments

Comments

@tikue
Copy link

@tikue tikue commented Sep 21, 2013

It looks like #570 regressed.

CGLGetPixelFormat failed.
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
[Switching to process 21117 thread 0x4f03]
0x0000000100fee747 in AzCreateSkiaDrawTargetForFBO ()
(gdb) bt
#0  0x0000000100fee747 in AzCreateSkiaDrawTargetForFBO ()
#1  0x0000000100eee099 in new_with_fbo () at azure_hl.rs:343
#2  0x000000010007b27a in render_task::__extensions__::render_23929::anon::anon::expr_fn_23935 () at constellation.rs:62
#3  0x00000001000713cc in render_task::__extensions__::create_22796::anon::expr_fn_22924 () at constellation.rs:62
#4  0x000000010006f958 in task::__extensions__::spawn_with_22812::anon::expr_fn_22818 () at constellation.rs:62
#5  0x0000000100300c6c in task::spawn::spawn_raw::anon::expr_fn_20955 ()
#6  0x00000001003a1254 in rt::task::__extensions__::build_start_wrapper::anon::anon::expr_fn_27304 ()
#7  0x00000001002a407c in unstable::finally::Finally$x24__extensions__::finally_16533::_199ab8d6eb226980IY::v0.8$x2dpre ()
#8  0x000000010039ebc5 in rt::task::__extensions__::run::anon::expr_fn_27232 ()
#9  0x00000001003a1729 in rt::task::Unwinder::try::try_fn::__rust_abi::VZ ()
#10 0x00000001003a1687 in rt::task::Unwinder::try::try_fn::_f279c486734e2394VZ::v0.8$x2dpre ()
#11 0x00000001021f9574 in rust_try (f=0x200, fptr=0x0, env=0x11d28a830) at rust_builtin.cpp:523
#12 0x000000010039ea92 in rt::task::Unwinder::try::_199ab8d6eb226980VZan::v0.8$x2dpre ()
#13 0x000000010039e926 in rt::task::Task::run::_199ab8d6eb226980iQam::v0.8$x2dpre ()
#14 0x00000001003a0ea7 in rt::task::__extensions__::build_start_wrapper::anon::expr_fn_27289 ()
#15 0x00000001004252a5 in rt::context::Context::new::task_start_wrapper::__rust_abi::Yz ()
#16 0x0000000100425257 in rt::context::Context::new::task_start_wrapper::_1b9fdc38dc3bcfa4Yz::v0.8$x2dpre ()
(gdb) 

To replicate:

  1. ./servo http://en.wikipedia.org/wiki/Nero
  2. Click Roman Emperor link
  3. Click backspace
  4. Click Roman Emperor link again.
@tikue
Copy link
Author

@tikue tikue commented Sep 21, 2013

This was occuring because script tasks were shutting down the compositor prematurely upon closure.

bors-servo pushed a commit that referenced this issue Sep 23, 2013
Fixes #967 and #965 

This has been wrong for a long time. Previously, only the pipeline associated with the root frame evicted would be shut down. 1) It shouldn't necessarily be closed, because there could be references to it still in the navigation context, and 2) Presumably none of the children pipelines of the root frame were ever exiting.

It's hard to test this right now because #965 covers up other pipeline exiting issues, but when that's fixed, a pathological case in which things would have broken down would be:

1) Load a page with an iframe that contains a link
2) Click the link
3) Press backspace to navigate back
4) Navigate to any new page, at which point the forward page would be evicted from the navigation context, and the outer frame's pipeline would be shut down improperly.
5) Press backspace, at which point there is no longer a pipeline for the old page, because it was shut down prematurely. Presumably this would cause a crash.

I also changed the FrameTree function ```find_mut``` to ```find``` because find_mut implies it's doing something to cause mutability, but the mutability is caused by the type of object being iterated over, nothing else.

Additionally, script was exiting completely when receiving an exit message. Instead, it needs to handle exit messages according to who sent it. It should only close the subframes of the frame whose pipeline sent the exit message. This is now fixed.

Inexplicably, script was also closing the compositor upon receiving an exit message. This doesn't seem like it'd ever be the right thing to do. I've fixed that. I don't think anyone shuts down the compositor now. It seems like it should occur in servo.rc, but I haven't added it because I'm not positive.
bors-servo pushed a commit that referenced this issue Sep 23, 2013
Fixes #967 and #965 

This has been wrong for a long time. Previously, only the pipeline associated with the root frame evicted would be shut down. 1) It shouldn't necessarily be closed, because there could be references to it still in the navigation context, and 2) Presumably none of the children pipelines of the root frame were ever exiting.

It's hard to test this right now because #965 covers up other pipeline exiting issues, but when that's fixed, a pathological case in which things would have broken down would be:

1) Load a page with an iframe that contains a link
2) Click the link
3) Press backspace to navigate back
4) Navigate to any new page, at which point the forward page would be evicted from the navigation context, and the outer frame's pipeline would be shut down improperly.
5) Press backspace, at which point there is no longer a pipeline for the old page, because it was shut down prematurely. Presumably this would cause a crash.

I also changed the FrameTree function ```find_mut``` to ```find``` because find_mut implies it's doing something to cause mutability, but the mutability is caused by the type of object being iterated over, nothing else.

Additionally, script was exiting completely when receiving an exit message. Instead, it needs to handle exit messages according to who sent it. It should only close the subframes of the frame whose pipeline sent the exit message. This is now fixed.

Inexplicably, script was also closing the compositor upon receiving an exit message. This doesn't seem like it'd ever be the right thing to do. I've fixed that. I don't think anyone shuts down the compositor now. It seems like it should occur in servo.rc, but I haven't added it because I'm not positive.
bors-servo pushed a commit that referenced this issue Sep 23, 2013
Fixes #967 and #965 

This has been wrong for a long time. Previously, only the pipeline associated with the root frame evicted would be shut down. 1) It shouldn't necessarily be closed, because there could be references to it still in the navigation context, and 2) Presumably none of the children pipelines of the root frame were ever exiting.

It's hard to test this right now because #965 covers up other pipeline exiting issues, but when that's fixed, a pathological case in which things would have broken down would be:

1) Load a page with an iframe that contains a link
2) Click the link
3) Press backspace to navigate back
4) Navigate to any new page, at which point the forward page would be evicted from the navigation context, and the outer frame's pipeline would be shut down improperly.
5) Press backspace, at which point there is no longer a pipeline for the old page, because it was shut down prematurely. Presumably this would cause a crash.

I also changed the FrameTree function ```find_mut``` to ```find``` because find_mut implies it's doing something to cause mutability, but the mutability is caused by the type of object being iterated over, nothing else.

Additionally, script was exiting completely when receiving an exit message. Instead, it needs to handle exit messages according to who sent it. It should only close the subframes of the frame whose pipeline sent the exit message. This is now fixed.

Inexplicably, script was also closing the compositor upon receiving an exit message. This doesn't seem like it'd ever be the right thing to do. I've fixed that. I don't think anyone shuts down the compositor now. It seems like it should occur in servo.rc, but I haven't added it because I'm not positive.
bors-servo pushed a commit that referenced this issue Sep 24, 2013
Fixes #967 and #965 

This has been wrong for a long time. Previously, only the pipeline associated with the root frame evicted would be shut down. 1) It shouldn't necessarily be closed, because there could be references to it still in the navigation context, and 2) Presumably none of the children pipelines of the root frame were ever exiting.

It's hard to test this right now because #965 covers up other pipeline exiting issues, but when that's fixed, a pathological case in which things would have broken down would be:

1) Load a page with an iframe that contains a link
2) Click the link
3) Press backspace to navigate back
4) Navigate to any new page, at which point the forward page would be evicted from the navigation context, and the outer frame's pipeline would be shut down improperly.
5) Press backspace, at which point there is no longer a pipeline for the old page, because it was shut down prematurely. Presumably this would cause a crash.

I also changed the FrameTree function ```find_mut``` to ```find``` because find_mut implies it's doing something to cause mutability, but the mutability is caused by the type of object being iterated over, nothing else.

Additionally, script was exiting completely when receiving an exit message. Instead, it needs to handle exit messages according to who sent it. It should only close the subframes of the frame whose pipeline sent the exit message. This is now fixed.

Inexplicably, script was also closing the compositor upon receiving an exit message. This doesn't seem like it'd ever be the right thing to do. I've fixed that. I don't think anyone shuts down the compositor now. It seems like it should occur in servo.rc, but I haven't added it because I'm not positive.
bors-servo pushed a commit that referenced this issue Sep 24, 2013
Fixes #967 and #965 

This has been wrong for a long time. Previously, only the pipeline associated with the root frame evicted would be shut down. 1) It shouldn't necessarily be closed, because there could be references to it still in the navigation context, and 2) Presumably none of the children pipelines of the root frame were ever exiting.

It's hard to test this right now because #965 covers up other pipeline exiting issues, but when that's fixed, a pathological case in which things would have broken down would be:

1) Load a page with an iframe that contains a link
2) Click the link
3) Press backspace to navigate back
4) Navigate to any new page, at which point the forward page would be evicted from the navigation context, and the outer frame's pipeline would be shut down improperly.
5) Press backspace, at which point there is no longer a pipeline for the old page, because it was shut down prematurely. Presumably this would cause a crash.

I also changed the FrameTree function ```find_mut``` to ```find``` because find_mut implies it's doing something to cause mutability, but the mutability is caused by the type of object being iterated over, nothing else.

Additionally, script was exiting completely when receiving an exit message. Instead, it needs to handle exit messages according to who sent it. It should only close the subframes of the frame whose pipeline sent the exit message. This is now fixed.

Inexplicably, script was also closing the compositor upon receiving an exit message. This doesn't seem like it'd ever be the right thing to do. *Edit: this is _only_ the right thing to do when received from the window.* I've fixed that. I don't think anyone shuts down the compositor now. *Edit: the script shuts down the compositor only when receiving an exit from the window.*
@kmcallister
Copy link
Contributor

@kmcallister kmcallister commented Oct 11, 2013

Supposedly fixed by #966, but I can't test with the given instructions due to #582.

@jdm
Copy link
Member

@jdm jdm commented Apr 18, 2014

Still can't test due to #1976.

@narfg
Copy link

@narfg narfg commented Jun 24, 2015

I can't reproduce this anymore so I guess it was fixed.

@metajack metajack closed this Jun 24, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.