NetSurf OS3 - testing!

[chris]

Surprise!  I'm not dead.

For anybody who is interested, I would like to know if this build of NetSurf: https://www.cy2.uk/tmp/netsurf_os3_test.lha

a) works at all (ie. gets to the main windows without crashing)
b) can access secure sites like https://www.howsmyssl.com

If I run it here it crashes early on under OS3.5, but not under OS4 (under OS4 has other problems but it isn't designed to run there so that may be normal)

If it does crash I'd like to know what system/OS you are using.  If you can get any information about where it is crashing (Enforcer hits, etc) that may prove useful.

Cheerio!

[chris]

It start without problems

Well, that's encouraging anyway.

It seems like the archive is packed with some newer unsupported algorithm unknownst to bog standard LHA.

Yes, sorry, xadmaster will be able to unpack it.

[chris]

It seems like the archive is packed with some newer unsupported algorithm unknownst to bog standard LHA.

I just checked and it extracts fine with LhA 2.15.

[chris]

And there are some errors with patchwork:

exec.library CreateIORequest(0x16C46D40,56)
Severity 2: ioReplyPort not initialized

This should now be fixed (archive updated)

exec.library InitSemaphore(0x1834DE1C)
Severity 2: structure is not cleared
PC=17202F9E TCB=16C17790 ("Background CLI")
Data: 1834DE1C 00000040 1834DE1C 0000000C 182B1706 00000020 1834DDCC 1834DDAC
Addr: 1834DE1C 1834DE18 1834DDEC 172314B0 16BFC432 16BBC5AC 120008F4 16BBC594
Stck: 17202FA2 0000002E 17202F50 00000020 1834DD8C 1834D980 16BBC5B8 172378A8
Stck: 1722C99A 16BBC5C4 17237A04 1722C99A 16BBC658 17311E38 00000357 00000000
----> 17202F9E - "libs:amissl/amissl_v111a.library"  Hunk 0000, Offset 00068A26

I don't manually call any AmiSSL functions so this is probably internal to AmiSSL.

[chris]

It seems like the archive is packed with some newer unsupported algorithm unknownst to bog standard LHA.

I just checked and it extracts fine with LhA 2.15.

Hm, it did well with Directory Opus, somehow....

Admittedly I didn't check that exact file, just one which was compressed the same way.  For some reason it wasn't actually compressed the same way 
I've lowered the compression level and checked LhA can extract from it.  When I upload a new archive it should extract without problems now.

edit Ah, think there's some default set on the CI server to lower it to -lh5- so my local files were wrong but the normal CI build archives were fine.

[chris]

exec.library InitSemaphore(0x1283E558)
Severity 2: structure is not cleared
PC=128564A2 TCB=12830E20 ("Background CLI")
Data: 1283E59C 00000000 00000800 00000001 124A84FE 04A0C9CF 04A0AAF5 14E30B14
Addr: 1283E558 1283E598 14FB4B37 1283E530 128373A6 1283E48C 120008F4 12837356
Stck: 128564A6 00000009 00000005 14FB4B37 124A865F 1283F7D0 12855BAA 128701CE
Stck: 80001001 00000001 00000000 1283E48C 120008F4 1286FE36 1202A1E8 1283E48C
----> 128564A2 - "LIBS:render.library"  Hunk 0000, Offset 00000962

This is render.library, either a render.library bug or due to how I'm calling it.  Either way unlikely to be able to locate the cause.

exec.library CreateIORequest(0x128F4B98,56)
Severity 2: ioReplyPort not initialized
PC=14FBC734 TCB=12830E20 ("Background CLI")
Data: 00000038 00000002 00000001 129F6FC4 14ED48A6 14ED4278 1283732A 12837346
Addr: 128F4B98 129FEA7C 150E07FA 128ED00C 128E64C4 12837490 120008F4 128372C8
Stck: 14FBC738 150E0A3C 00000000 129F769C 129F6FC4 14ED4DAA 00000000 14ED48A6
Stck: 129F6FC4 129F6FC4 128F4B98 00000000 08000000 00000000 06000000 14ED48A6
----> 14FBC734 - "NetSurf"  Hunk 0000, Offset 0018BC1C

Bit confused about this one.  I only call CreateIORequest in three places.  Two of them, the second parameter is 16 (not 56), the third one I'd need to check what the second parameter is but it is in a code path which isn't used.

exec.library Enable()
Severity 2: Disable() missing
PC=1208F2E6 TCB=12830E20 ("Background CLI")
Data: 000000FF 00000015 12104EEC 12104E74 12836BA8 1200231C 0000FFFF 00000003
Addr: 12000A8A 1208F9A8 00000000 1200225C 12002366 1204413C 120008F4 12002354
Stck: 12002354 1208F2EA 1208EEC0 00000003 00001284 28BA200C 6100644A 12013480
Stck: 048008E3 0000010C FFFFFFFE 120239DC 0480948A 120026A0 04804D1B 00000B5D

Don't know where this comes from, I don't call Enable anywhere.

And it crashes when clicking the slashdot link.
That's this one:

TASK TRAPPED
Illegal instruction
TRAP=0x04  SR=0x0000  PC=0x12612D22  TCB=0x12629E18
  PC: 00000000 1200267C 00000000 00000000 00000000 00000000 00000000 00000000
  PC: 12612D40 12612DB8 00000000 00001261 31B00000 01F81261 2B240000 00001261
Data: 00000001 FFFFFF01 00000001 00000000 00000014 00000001 00000002 129A6EFC
Addr: 1260B8D0 1260B894 1260B8D0 00000000 00000000 138597C4 12612F3C 1260B880
Stck: 12B73490 1260B8D0 12EC1EC4 1260B8D0 12EC10FC 12B737D2 12B73B22 1260B8D0
----> 12B73490 - "NetSurf" Hunk 0000 Offset 00135FC0
----> 12EC1EC4 - "NetSurf" Hunk 0000 Offset 004849F4
----> 12EC10FC - "NetSurf" Hunk 0000 Offset 00483C2C
----> 12B737D2 - "NetSurf" Hunk 0000 Offset 00136302
----> 12B73B22 - "NetSurf" Hunk 0000 Offset 00136652
Stck: 1260B8D0 12EC1EC4 00000000 12B74C68 1260B8D0 13F68494 00000000 00000000
----> 12EC1EC4 - "NetSurf" Hunk 0000 Offset 004849F4
----> 12B74C68 - "NetSurf" Hunk 0000 Offset 00137798
Name: "Background CLI"  CLI: "NetSurf"

That would be useful if I could get debug symbols working properly, unless somebody can look at the asm and give me a clue as to what's going wrong?

Idea: make the tab width a max width, so it doesn't get too big.

Tabs are broken on OS3 anyway... but this is a good idea.

[chris]

I ran upodateto314 script and I still have a problems. No pictures are displayded with Netsurf and it and when I trying to surf any web page it makes everything bog slow.

I have 3.1.4 kickstart and O3.9 BB1&2 wich is updated with 3.1.4 components.

Does the old version work with 3.1.4?
By which I mean the latest build here: https://ci.netsurf-browser.org/builds/amigaos3/

[chris]

Does the old version work with 3.1.4?
By which I mean the latest build here: https://ci.netsurf-browser.org/builds/amigaos3/

No, it doesn't work downloaded NetSurf-gcc-4567.lha and same symptoms, version wich I had was from late 2018.

I have 1mb kickstart, wich has 3.1.4 components, including intuititon library.  But also a peterk's icon.library and few filesystems. Nothing really excotiq.

OK, for the purposes of this test that's not interesting

[chris]

The LhA problem is fixed (I just haven't replaced the download yet). Just to be clear, it was only broken on my local buildsystem, the official builds were archived correctly.

I thought I'd fixed the crash on exit ages ago.

I'm going to need some help decoding those hits.

[chris]

I'm going to need some help decoding those hits.

Sure, let me know how I could help out.

Cool, thanks. It's mostly a case of figuring out what's being called incorrectly. Unfortunately I've never managed to get findhit working with gcc, otherwise this would be easy.

[chris]

I've tried both, with various -g options 

[chris]

I've tried both, with various -g options 

Perhaps this will give some insights (no expert myself): http://eab.abime.net/showthread.php?t=90143

Something to do with LINE debugging yes/no... 

That suggests -g should work.

*EDIT: do you have a debug version of the NetSurf executable?

I think my download is built with -gstabs

Chris

[chris]

I think my download is built with -gstabs

It seems there is no line number information for all offsets (tried here myself).

Yeah, that was the problem I had last time I tried.

[chris]

Did some more searching and stumbled on this thread: http://eab.abime.net/showthread.php?t=84208

A link can be found to a util called 'FindHunkOffset' in post #12. Not sure if it helps, but at least it's reporting 'something'...

Code: [Select]

12.Ram Disk:> FindHunkOffset Utilities:Comm/Browse/NetSurf/NetSurf 0 0x185C86
Section 0, offset 0x00185c86 is at
_ami_libs_close + 0x000001a6

12.Ram Disk:> FindHunkOffset Utilities:Comm/Browse/NetSurf/NetSurf 0 0x172872
Section 0, offset 0x00172872 is at
_main + 0x000006f0

Ah, yes, that's really useful.  The line number would be helpful though, the tool says it can report that but obviously the debug symbols aren't quite right (probably the same reason findhit/gccfindhit don't work).  I can't see anything wrong in ami_libs_close but I may have now found and fixed the CreateIORequest and startup LONG WRITE etc hits.

*EDIT: Also did some searching on 'addr2line', but this involves another option (information can be found in various places).

To use addr2line we first have to compile our program with gcc, using the -ggdb option.

If that doesn't help either, I have no idea how you would need to develop and debug your creation to be of any use.

I've rebuilt it with the above fixes and -ggdb instead of -gstabs.  I'm not convinced it will help.

[chris]

Tried some various things with addr2line here, no luck though Unless someone is willing to help out to get proper debugging in place, I don't think it's very useful to test further if you can't exactly pinpoint the location where things get messy.

*EDIT: perhaps possible addtional interesting information can be found on the following locations:
http://eab.abime.net/showthread.php?t=93055
https://franke.ms/amiga/gdb-eclipse.wiki

It looks like -g might be better than -ggdb or -gstabs
https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Debugging-Options.html