NetSurf 3.6 web browser released!

[apsturk]

I reread your question. Here is the stack trace
Stack trace:
    [frontends/amiga/gui.c:5356] ami_gui_splash_open()+0x21c (section 1 @ 0x1773D8)
    [frontends/amiga/gui.c:5352] ami_gui_splash_open()+0x214 (section 1 @ 0x1773D0)
    native kernel module newlib.library.kmod+0x000020a4
    native kernel module newlib.library.kmod+0x00002d54
    native kernel module newlib.library.kmod+0x00002ee8
    _start()+0x170 (section 1 @ 0x16C)
    native kernel module dos.library.kmod+0x00024c18
    native kernel module kernel+0x00042654
    native kernel module kernel+0x000426d4



Thanks

[chris]

I reread your question. Here is the stack trace

OK, that's a new one. What I think has happened is the splash window has failed to open, and then crashed because I've not checked that it is open.

There's very little reason for that to fail. Lack of memory? (unlikely). Even if it can't open the image (Resources/splash.png - check it in Multiview), the window should still appear.

[olsen]

Ah, looks like strftime gets replaced. Before I change this, do you know if this comment is valid?

Code: [Select]

/* Although these platforms might have strftime or strptime they
 *  appear not to support the time_t seconds format specifier.
 */

Yes, this is still valid. clib2 does not support the strftime() "%s" conversion specifier. "%s" appears to be a Unix addition, and it is not part of the C99 specs. I could easily add it, though, if it is needed.

Looking at the source code of NetSurf 3.6, it appears that there is a workaround in place which performs the conversion with snprintf(). Makes you wonder why strftime() is used in the first place

As for strptime(), this is not part of the C99 specs either, and quite complex to implement. This seems to be a Unix addition, too. Again, NetSurf has various workarounds for strptime() in place which do the job just fine.

NetSurf neither replaces vsnprintf() nor strftime(), as far as I can tell. There goes my theory as to what interferes with the JSON data generation. I'm really puzzled how this could go so spectacularly awry... Could you check the linker map? It should show where the vsnprintf() and strftime() code comes from, exactly.

That said, it's not difficult to generate the same data using the __get_slab_allocations() and __get_slab_usage() API functions in clib2 if you wanted to implement it yourself. I just thought I'd save you the effort and put it into __get_slab_stats().

[chris]

@olsen
I'm afraid the map file means nothing to me, but it's here if you want to decode it: http://www.cy2.uk/tmp/map.txt.gz

@apsturk
Please try build 3788 or newer from http://ci.netsurf-browser.org/builds/amiga/
It'll probably just crash later on (I have fixed the crash you're seeing), but I'd like you to run it with:
netsurf -v *>ram:ns.log

Then email me the log file.

[olsen]

@olsen
I'm afraid the map file means nothing to me, but it's here if you want to decode it: http://www.cy2.uk/tmp/map.txt.gz

Thank you, it's not that cryptic, it's just too long

Here are the "interesting" bits (for given values of "interesting"):

-- 8< --

 .text          0x0056a724       0x90 /opt/netsurf/m68k-unknown-amigaos/cross/lib/gcc/m68k-unknown-amigaos/3.4.6/../../../../m68k-unknown-amigaos/lib/libm.a()
                0x0056a724                _vsnprintf

 .text          0x005886e0      0xe98 /opt/netsurf/m68k-unknown-amigaos/cross/lib/gcc/m68k-unknown-amigaos/3.4.6/../../../../m68k-unknown-amigaos/lib/libc.a(time_strftime.o)
                0x00589408                _strftime

-- 8< --

This says that both vsnprintf() and strftime() come from the libm.a and libc.a linker libraries, which are part of clib2, etc. It's odd that the reference to libm.a does not list the source file name (when did you last rebuild all these libraries from scratch?).

Anyhow, these library functions are not getting overridden by NetSurf, libcurl, libssl, libgcc, etc. code.

Which collapses another theory of mine.

How does the code look like which fails to produce the correct JSON data? Have you already checked it in?

[Oldsmobile_Mike]

Do you mean that you can't do this (see picture)

Well sure I can.  Just with older versions (and their very slow redraw/refresh rate), clicking & dragging to resize the window took something like two minutes and would often lead to the program crashing entirely.

Just tested, it does work a bit better now.  

[chris]

How does the code look like which fails to produce the correct JSON data? Have you already checked it in?

It's checked in, here it is:

Code: [Select]


static int ami_memory_slab_stats_cb(void *user_data, const char *line, size_t line_length)
{
BPTR fh = (BPTR)user_data;
long err = FPuts(fh, line);

if(err != 0) {
return -1;
} else {
return 0;
}
}

fh = Open(fname, MODE_NEWFILE);
__get_slab_stats(fh, ami_memory_slab_stats_cb);
Close(fh);


[apsturk]

Well I reinstalled it into a folder and it works. The installer just put stuff everywhere in my work petition and I grabbed everything I thought was with it into a folder but missed some the were not seen in icon view. It works and it is nice

Thank you

[olsen]

It's checked in, here it is:

Code: [Select]


static int ami_memory_slab_stats_cb(void *user_data, const char *line, size_t line_length)
{
BPTR fh = (BPTR)user_data;
long err = FPuts(fh, line);

if(err != 0) {
return -1;
} else {
return 0;
}
}

fh = Open(fname, MODE_NEWFILE);
__get_slab_stats(fh, ami_memory_slab_stats_cb);
Close(fh);


Thank you, this looks like it should.

This suggest that the problem may be with the clib2 vsnprintf() code. I only tested the plain libc version (no floating point support), whereas NetSurf uses the libm version (with floating point support). I'll have another go at reproducing the problem.

One last thing: does the behaviour change in any way if you replace Open()/FPuts()/Close() with fopen()/fputs()/fclose(), or store the file on a different volume (i.e. don't save to RAM:, save to a hard disk drive)?

[chris]

One last thing: does the behaviour change in any way if you replace Open()/FPuts()/Close() with fopen()/fputs()/fclose(), or store the file on a different volume (i.e. don't save to RAM:, save to a hard disk drive)?

I just tried saving to RAM: (previously I saved to HD) and the result is the same

[utri007]

I made some benchmarking an results were weird? First there is no memory issue, or it is very minimal.

Test was made just refreshing amigaworld.net FrontPage. 060 and 040 tells CPU, next numbers are secons. Kb free ram is how much my 040/32mb ram system had free fast ram.

First test was amigaworld.net, no big diffrences.

CPU / SEC 060  17    14,7   15,0   15,3   15,6   14,6   14,8
CPU / SEC 040  21,9 19,9   18,7   18,9   19,5   19,1   19,2
kb free ram       3921         3882  3864            3888

Next test was amiga.org, here I got weird results. After some time my 040 is faster or equal with my 060. So slab allocator gives huge benefit to 68040 cpu, but not for 68060 cpu? After first load rendering time is less than half?

Test was made refreshing amiga.org FrontPage and last two sec values are amiga.org forums and amigaworld.  Last two kb values are free ram amiga.org forums and amigaworl.net.

amiga.org                                                                          
CPU / SEC 060 30,9  24,3  23,8  22,9   25,8   23,5    22,0     27,8      15.1      
CPU / SEC 040 65,1  25,7  26,3  22,4   24,5   24,5    24,2     34,5      19,3
kb free ram     945            927   873    907                          966       1257

Both Amigas has has Orinoco Silver Wlan card and Genesis TCP/IP stack. No reboot between tests.

[utri007]

Reproduced test so that my 4G router/wlan access point was near of Amigas, results were same. There is also a pattern, 5th refresh is slower than previous and 6th faster again.

How can slab allocator be so much faster with 68040 than 68060?

[myzar74]

I made some benchmarking an results were weird? First there is no memory issue, or it is very minimal.

Test was made just refreshing amigaworld.net FrontPage. 060 and 040 tells CPU, next numbers are secons. Kb free ram is how much my 040/32mb ram system had free fast ram.

First test was amigaworld.net, no big diffrences.

CPU / SEC 060  17    14,7   15,0   15,3   15,6   14,6   14,8
CPU / SEC 040  21,9 19,9   18,7   18,9   19,5   19,1   19,2
kb free ram       3921         3882  3864            3888

Next test was amiga.org, here I got weird results. After some time my 040 is faster or equal with my 060. So slab allocator gives huge benefit to 68040 cpu, but not for 68060 cpu? After first load rendering time is less than half?

Test was made refreshing amiga.org FrontPage and last two sec values are amiga.org forums and amigaworld.  Last two kb values are free ram amiga.org forums and amigaworl.net.

amiga.org                                                                          
CPU / SEC 060 30,9  24,3  23,8  22,9   25,8   23,5    22,0     27,8      15.1      
CPU / SEC 040 65,1  25,7  26,3  22,4   24,5   24,5    24,2     34,5      19,3
kb free ram     945            927   873    907                          966       1257

Both Amigas has has Orinoco Silver Wlan card and Genesis TCP/IP stack. No reboot between tests.

060 clocked at ? I get 9,2/5,9 for amigaworld and 13,4/7,5 for amiga.org with my vampire, it seems alot faster than a 060 with netsurf

[utri007]

060 clocked at ? I get 9,2/5,9 for amigaworld and 13,4/7,5 for amiga.org with my vampire, it seems alot faster than a 060 with netsurf

Vampire is 3.6x faster than my 060

[chris]

060 clocked at ? I get 9,2/5,9 for amigaworld and 13,4/7,5 for amiga.org with my vampire, it seems alot faster than a 060 with netsurf

Oh, is this working on the Vampire now? What was the problem?

[wawrzon]

Oh, is this working on the Vampire now? What was the problem?

is this even the same vesion of netsurf? maybe they are using artis sdl port?

@utri

im not sure if your benchmarking bears any actual meaning. there is so much factors the speed you measure may depend upon, the actual internet rates, the likely varying contents of the pages you are downloading and therefore the possibly varying acces times. above all you dont even use a cable connestion but wlan.. who even cares what stack or interface you use? id test against a locally saved page to at least eliminate few of these unknown variables. but i have said that before..