(solved) NetSurf very unstable?

By the way, I've installed & tested NetSurf v3.2, and it also crashes on exit. Maybe not as catastrophically, so I might be able to get a crash log... if it would be of any use?

@Chris
Quote:
O.K. It was easier said than done though. I was able to highlight the text in 2369 and copy & paste it into an editor. However, as soon as I tried to highlight the text in 2398 my system froze completely. I had to use the "save as source" menu item and copy the text from the saved file. Here is what I got:

# Automatically generated by NetSurf build system

# This NetSurf was built from a branch (jenkins-BUILD=ppc-amigaos,BUILD_JS=json,CC=gcc,TARGET=amiga-2369).

# This build carries the CI build number '2369'

Built by (jenkins) from jenkins-BUILD=ppc-amigaos,BUILD_JS=json,CC=gcc,TARGET=amiga-2369 at revision 60c33e041009b1c04ebf117ead7bd0702b848320 on 21.11.2014

Built on cislave5 in /var/lib/jenkins/workspace/netsurf/BUILD/ppc-amigaos/BUILD_JS/json/CC/gcc/TARGET/amiga/

Working tree has 1 modification

?? NetSurf_Amiga/

------------------------------------------------------------------------

# Automatically generated by NetSurf build system

# This NetSurf was built from a branch (jenkins-BUILD=ppc-amigaos,BUILD_JS=json,CC=gcc,TARGET=amiga-2398).

# This build carries the CI build number '2398'

Built by (jenkins) from jenkins-BUILD=ppc-amigaos,BUILD_JS=json,CC=gcc,TARGET=amiga-2398 at revision 5f57a39130aea9829ea9d870e55f4fb19d7cbec8 on 27.11.2014

Built on cislave5 in /var/lib/jenkins/workspace/netsurf/BUILD/ppc-amigaos/BUILD_JS/json/CC/gcc/TARGET/amiga/

Working tree has 1 modification

?? NetSurf_Amiga/

@xenic

Thanks for doing that, these are the changes:
http://git.netsurf-browser.org/netsur ... 29ea9d870e55f4fb19d7cbec8

The new scheduler mentioned there I mostly reverted back, but there might be some minor differences. Given the list of changes there, it's unlikely to be anything else. I suspect that timer events are getting missed. I used to have a loop to ensure all the scheduled events were getting fired, I think the first thing I'll do is add that back in to see if it fixes the problem.

Hopefully should find ten mins to do that tonight.

Right... it's way later now than I hoped, but I've looked at the scheduler and can't see anything particularly wrong. I haven't added any extra looping as the only way it could be missing events is if it triggers before the time of the event. I can see a potential problem there if the clock gets fiddled with, but I would be surprised if that would cause such a persistent problem. I've added some logging to see if that might be the cause. It can easily be fixed, and I will fix it, but not at this time of night. BUT this might not be causing the problem as the scheduler has always worked like this.

build 3635 or later has the extra logging. Please run it as:
netsurf -v *>ram:ns.log
Then send me the ns.log or upload it somewhere

@Chris
It appears that my crash-on-exit with NetSurf is down to my configuration file. I'm not yet sure, but it seems it may be due to "cache_bitmaps:1". Does that make any sense?

@ChrisH

I'll try it here later. Does cache_bitmaps:2 also crash?

@Chris
Don't bother trying it, as it's probably not the cause after all. But I am still fairly certain it's something in my config file...

I'm now thinking it might be my use of a Public screen (which OS4 auto opens & closes for me)... But need more testing to be certain.

edit: The Public screen cause is still looking plausible (and so increasing in likelyhood).

@Chris
Quote:
I think I've accidently discovered something that may be important. I tested with build 3640 and saved the log after Netsurf froze. When I retested to be sure it was freezing consistantly, I accidently mistyped the command and the log data was printed in the shell instead of the log in ram. However, I didn't get any freeze at Sourceforge and copying the "about:testament" text did not did not cause a freeze. Apparently typing the log text to the shell slowed Netsurf down and altered the internal timing.

My tests seem to confirm your scheduler timing suspicions. Assuming that your email address in the Netsurf guide is correct, you should be receiving an email with an lha archive of the ns.log attached.

@xenic

Quote:

Interesting. The log didn't show anything much of note, so I've gone ahead and replaced the scheduler withone which triggers the events by relative time and doesn't use a separate heap to pick the events off of. This should be much more reliable.... however...
When I direct logging output to the Shell, it crashes a lot and I can't see any reason why. Running without logging is working fine (haven't tried redirecting to a file, will try that in a minute - I'm typing this in this version of NetSurf)

It is also still hanging for me on the originally linked sourceforge page, but I don't know if that is even the same problem.

Build 3641 has the improved scheduler, let me know if it makes a difference (and a log as before might be helpful if it doesn't).

@ChrisH

Quote:

I thought we'd fixed that?

@Chris
Quote:

O.K. I need to take care of some things before I can try build 3641 but I will try to get to it a little later.

When I test highlighting the about:testament text for a copy, sometimes a console pops up with an error message before Netsurf freezes the system. I ran Netsurf from a shell and redirected error output to a file that I could recover after a reboot. Here is what the error is:

assertion "end <= text->utf8_data_size" failed: file "render/textplain.c", line 1257

@Chris
As I recall, "we" fixed OS4 failing to close the Public screen, because Netsurf released the screen too many times (leading to a negative usage count which OS4 took to mean it was in use).

I don't recall any fixing of instability from using Public screens.

@Chris
I tested build 3641 it crashed instead of freezing. I sent the ns.log and crashlog in an email. If nobody else is experiencing this problem with Sourceforge project pages and copying the about:testament text, there may not be anything you can do. It would be nice if someone else would test loading a Sourceforge project page.

@xenic
Of course I get a crash visiting the SourceForge page, but you seem to be doing a good job of helping Chris track down the problem, so I don't see the need to help out...

.. plus I originally started this thread about the almost guaranteed crashes I got when quitting NetSurf, and I'm still trying to track down the cause of that... Never mind that until recently I couldn't be sure if my crashes might intefere with tracking-down the SourceForge crashes.

Are you both using X1000s? That might be relevant.
ChrisH - If so, can you try on your SAM with the same config and see if that crashes on sf.net? (and/or on exit whilst you're there!)

The other thing I notice had changed between those revisions, is some time calculation now uses EClock instead of gettimeofday. AFAIK it is only used for the time display (Done 10.1s or whatever) but there's an outside chance it might be interfering with something else - or X1000 clock values are causing an unexpected overflow or something.

edit there is a potential problem with that, as it was being treated as a signed value, so would overflow at 2 million. I don't know what the frequency is reported as, but if it is CPU clock then 2GHz may overflow... I've just fixed it.

edit2 ...but I think there's something wrong with the modified scheduler as after a while it just...gives up.

@ChrisH
Actually, I was referring to others who haven't participated. Maybe it's just as well that this topic isn't filling up with unrelated posts. In all the testing I've done so far, Netsurf has never crashed when I quit it. So far build 3643 at http://ci.netsurf-browser.org/builds/amiga/ doesn't freeze at Sourceforge project pages (without logging turned on) so it appears Chris is making progress with that issue.

Are you running the debug kernal and/or have MUNGE in your CFE "os4_commandline" variable. That can cause crashes that don't happen with the normal kernal and no MUNGE.

@Chris Quote:
I can confirm that I do NOT get a crash when visiting that page using my Sam440. So it seems that your suspicion about it being related to the X1000's timer might be correct.

@xenic
No I do not use the debug kernel... although I probably should!

OK, there's clearly something obvious here I'm missing.

I think only my first timer message is being picked up by my GetMsg() loop, as I'm getting events stuck in the queue and it gets worse when logging is enabled (which means a longer wait before Wait()/GetMsg() comes round again):



The schedule code is here: http://git.netsurf-browser.org/netsur ... rontends/amiga/schedule.c

ami_schedule_handle() at the bottom has the GetMsg() loop in it.

That's called from http://git.netsurf-browser.org/netsur ... ontends/amiga/gui.c#n2840 and all the initialisation is in that file too (look for "schedulermsgport")

Please can somebody have a look and see if they can see anything I've done wrong? Thanks!

@Chris

Only had a brief look, but if there is a crash during exit, is possible pending IO checked and aborted? I notice SendIO() being used.

@Capehill

The crash during exit is something else, I'm more concerned with the timer messages not getting through atm, as that stops the browser working properly.