List items
Items from the current list are shown below.
Gecko
22 Jun 2024 : Day 266 #
I'm continuing to strip out methods today after eviscerating the code yesterday. There aren't many changes left and yesterday I established that none of the changed code is being executed before the crash. So I'm not confident that removing the changes will have any effect. But I don't have much else to do at this point so I may as well continue until there are no changes left to make.
It's anomalous though. I have packages built against the code with the commit reverted. I know that reverting all of the changes leaves me with a working browser. So something is clearly amiss.
Nevertheless I'm left with only a few changes now. The code is building and we'll see where this leaves us.
[...]
Code built, installed, executed. And we get the same result: a crash early on in the execution of the browser. I've removed so much code now that this doesn't feel right, so I need to check that something else hasn't broken along the way.
I've tried a whole bunch of things, including removing the profile, using different websites, restarting lipstick. None of this makes any difference.
Installing the packages for the version with working WebGL shows that things are still working for that. And when I then replace the library with the version of the library I've just built... well now that version works too, and with working WebGL as well. But of course the WebView is still broken with this version. But this clearly highlights that the problem isn't where I expected it to be.
So with much frustration I have to concede that something else — something bad — must have been happening elsewhere in the code.
Trying a second test, I install the packages for the version with broken WebGL. That gives the expected result (browser working; WebGL broken). Now I replace the library with my newly built one.
And now it crashes.
So the pattern is:
This is food for thought for sure. This suggests that the problem sits somewhere in the interface between the updated code and one of the EmbedLite code, the QtMozEmbed code, or the sailfish-browser code.
This at least gives me something to go on. I'm going to ruminate on this overnight and try to tackle it tomorrow. This is definitely progress, just not without raising new questions which I'll need to answer.
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
It's anomalous though. I have packages built against the code with the commit reverted. I know that reverting all of the changes leaves me with a working browser. So something is clearly amiss.
Nevertheless I'm left with only a few changes now. The code is building and we'll see where this leaves us.
[...]
Code built, installed, executed. And we get the same result: a crash early on in the execution of the browser. I've removed so much code now that this doesn't feel right, so I need to check that something else hasn't broken along the way.
I've tried a whole bunch of things, including removing the profile, using different websites, restarting lipstick. None of this makes any difference.
Installing the packages for the version with working WebGL shows that things are still working for that. And when I then replace the library with the version of the library I've just built... well now that version works too, and with working WebGL as well. But of course the WebView is still broken with this version. But this clearly highlights that the problem isn't where I expected it to be.
So with much frustration I have to concede that something else — something bad — must have been happening elsewhere in the code.
Trying a second test, I install the packages for the version with broken WebGL. That gives the expected result (browser working; WebGL broken). Now I replace the library with my newly built one.
And now it crashes.
So the pattern is:
- Install working WebGL packages followed by latest libxul.so... works.
- Install broken WebGL packages followed by latest libxul.so... crashes.
This is food for thought for sure. This suggests that the problem sits somewhere in the interface between the updated code and one of the EmbedLite code, the QtMozEmbed code, or the sailfish-browser code.
This at least gives me something to go on. I'm going to ruminate on this overnight and try to tackle it tomorrow. This is definitely progress, just not without raising new questions which I'll need to answer.
If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.
Comments
Uncover Disqus comments