duktape error NetSurf OS3

[DNADNL]

It works, i've just tried. You need to add these lines to user-startup
Assign >NIL: SSLROOT: SYS:Internet/AmiSSL/SSLROOT
Assign >NIL: SSLCERTS: SSLROOT:certs
Assign >NIL: SSLPRIVATE: SSLROOT: private  

Tested on AmiKit.

Thanks apj ! where is the user-startup file you talk about ?
Also, Netsurf works on AmiKit, even the OpenSSL. The problem is on Happiga (The Amiga distribution for Raspberry Pi), which is quite different.

It's getting to the point where adding extra logging might be the only way to figure it out.

LOG("blah blah blah")
Then run with -v

Ok, I'm going to try this.

[DNADNL]

Amiga.org's red problem is not  gone. But I noticed that majority of display / color problems are because of lack of colors. Opening Netsurf it's own screen makes Netsurf default start page looking good as it should be.

Could it be that DNADNL just opened it to own screen and noticed that it looks good?

Wich makes me wonder would render.library support HAM?

I can't tell you for Amiga.org, as it seems I don't have enough RAM to access it, but I went to the page I created for the tests and the whole pictures you can find on it are well displayed (the expected pictures, of course, so GIF, PNG, JPEG and ICO). So, I don't think it's only the welcome page which has changed.
Thanks for the user-startup location, I'll have a look.

[DNADNL]

Tried to create new thread to eab with Netsurf.

I can log on, start new thread, I can start to write text, but after I hit return and continue writing, every mark I try to wrote makes this error :

Assertion of condition "perror == parseutil_ok" failed file "utils/utf8.c", line 135.

Why is it so that error is because of true type fonts?

DNADNL

I'm running FBlit wich is small patch wich forces bitmaps to use FAST ram. There is only 2mb CHIP memory, wich is used Amiga custom chips. FBlit solves this problem.

So, I just tried my A1200 without FBlit and Amiga.org works, there is enough memory for that. You must have a background picture or something wich eats your emulated A1200 chip ram. After loading amiga.org there is a 300kb free chip ram. I needed to disable background picture.

Did NetSurf ask you to run FixFonts when you installed it ? Maybe the issue can come from the fact it doesn't ask yo to run it.

Even if I remove the background, that doesn't work.
FBlit, you say ? This one : http://aminet.net/package/util/boot/fblit ? OK, I'm going to check this out.
EDIT : When I launch FBlit, the system crashes ! ^^

[DNADNL]

How much ram you have total? How much when you get to OS?

I didn't say FBlit that you should try it. I'm prety sure that it doesn't work with emulatos, it hits hardware directly.

I'm on a Raspberry Pi 2, so basically 1GB RAM,
For Happiga, I think its 128 MB, but I'm not sure about it. Here are the data : http://puu.sh/qiSe2/2266414bfe.jpg

[DNADNL]

You have 8mb chip ram :O and it doesn't work??

Yeah, quite weird, huh ? ^^
I don't know why, really. I can see in NetSurf parameters that memory_cache_size is equal to 12 MB. i tried to put it to 8MB byt this doesn't work too.

[DNADNL]

OK, I launched NetSurf on AmiKit with lots of printf in the dukky.c file and used SnoopDOS to scan NetSurf activity. I didn't find anything different since the last time I did this but for the first time, two specific rows appeared in the SnoopDOS.log  ( | = new column):
DOpus5: DirectoryOp | Open | dopus5:system/seed | Write | OK
DOpus5: DirectoryOp | *Open | dopus5:system/seed | Write | OK

I don't know if it can help, but I prefer to say it.

[DNADNL]

Did the printf()s not print anything?

Did you put them at the start of every function in that file?

In fact, I replaced first the LOGs on the file by printf()s to see if there was a difference, but nothing appeared.

[DNADNL]

Hey, I can see this in the AmiKit output :
content/handlers/javascript/duktape/dukky;c:565 js_newcontext: Creating new duktape javascript content
FATAL 56: uncaught error

So, that means the error come after this LOG, in this function, right ?

[DNADNL]

Probably, yes.

Yay ! step by step we'll find the problem !
I added a LOG on EVERY row of the function, and now I can see the issue come from this line :
ctx = ret->ctx = duk_create_heap(
      dukky_alloc_function,
      dukky_realloc_function,
      dukky_free_function,
      ret,
      NULL);
(or from the if below : if (ret->ctx == NULL) , but I don't think so).
So maybe the issue comes from duk_create_heap, no ?

[DNADNL]

@dnadnl

im looking at your script. i have a proposition. could you make installing cygwin optional in future versions? as well as downloading and installation of packages should be available as option the user should be perhaps presented to confirm, after the script checked for required version of particular package and found it missing.

i intend to check how it works on my debian and ubuntu build environments. i may try to implement it myself and send you a diff, but ill probably start with commenting out the unnecessary sections.

You mean to create a UNIX/Linux version of NetScript ? Yeah, it's possible, and I think EyMenZ worked on this before. I will check his previous files.
However, I think it will be first a different Netscript version, as it could be difficult to install cygwin via a script which need cygwin to be executed ! ^^
I don't have a Debian/Ubuntu distribution for the moment, and I only have one SD Card for the Raspberry Pi (on which I have Happiga), but maybe a virtual machine could do the job...

Looks like it, yes.
So... maybe logging in that function next? (it's probably in duktape.c - You'll need to #include "utils/log.h")
It *could* be that it doesn't like the alloc/realloc/free functions being passed to it. I suppose we'll find that out anyway.

Yes ! I'm happy to finally progress ! ^^
I'll go on the files LOG-ification (neologism ^^) to finally flush out the DukTape mystery... ^^

[DNADNL]

@dnadnl
no worries, i have been playing around with it at night, just must see how to properly get around that autotools version issue, also i think either one needs to install the toolchain beforehand or resign on putting it in /opt and use the user accessible location.

but it isnt pressing at all. perhaps it isnt a bad idea at all to actually employ cygwin here.

Can you explain the autotools version issue you talk about ? Because NetScript works on many computers at work except one. I don't know why, but one day it decided to break down ! ^^ In fact, it doesn't come up to install cygwin tools (it says he has installed wget, but afterwards it can't use it... I deinstall/reinstall many times cygwin to try to solve the problem but it doesn't work... :-( But maybe it's specific to my computer.

the /opt/netsurf folder is very long to compile (about an hour, I think), so it's quite important to have the possibility to keep it. Except that, its location isn't important. however, if you move it, you need to do lots of links in the script which can be difficult to find. Also, is it a good idea to put it in the accessible location ? Because people could inadvertently delete it... Well, there is a lot to think ! ^^

[DNADNL]

i think you must know the issue, since your script exclusively tries to relink to autom4te 2.64 instead, as far as i have brought into my experience, today usual 2.69.

im sorry, i have not looked into that further. been busy trying to get rid of some compiling issues on aros68k, i am looking forward to having odyssey web browser compiled there for 68k. but ill try to contribute to this effort as much as i able too as well.

btw. do i understand well, that the restriction is due to one machine? so i can try to employ any autom4te set i have installed? since i dont remember that problem installing netsurf toolchain by hand..

Yes, the problem is only on one computer, and I think you can use any autom4te.

You're right, maybe the issue comes from autom4te, but if it's the case, why do I not have a problem with the other computers, as they use the same NetScript and so the same autom4te to work ? ... Mystery ! ^^

I would be interested in your work on Odyssey, as I wanted to do quite like NetScript but for Odyssey. Is the Big-Endian problem solved ?

[DNADNL]

A-ha!  Managed to get Duktape debug working with a #define DUK_USE_DPRINT.

Don't really understand the output though, and there's a ton of it.

Line 57817 of duktape.c: (duk_js_compiler.c:442)

Code: [Select]

if (expect >= 0 && comp_ctx->curr_token.t != expect) {
DUK_D(DUK_DPRINT("parse error: expect=%ld, got=%ld",
                (long) expect, (long) comp_ctx->curr_token.t));
DUK_ERROR_SYNTAX(thr, DUK_STR_PARSE_ERROR);
}

expect=50, curr_token.t=1

Hmm, I run it again with DUK_USE_DDPRINT and it fails in a different place.  I think this might be Duktape memory being trashed, and as it happened to Artur with clib2 too, maybe it is clib trashing memory?

Sorry, we can't see anything in your attached thumbnail. BTW, I don't know how to do this (attached thumbnail) when writing a post. ^^
I'll go on the LOG way to see if it brings me to the same part of the code.

[DNADNL]

Aw, I wanted to go on LOG-ing everything, but for this I need to compile regularly NetSurf with DukTape. Unfortunately, i can't now, it seems there is an issue :

Code: [Select]

make: *** [Makefile:809: build-CYGWIN_NT_6_1_WOW-amigaos3/content_handlers_javascript_duktape_dukky.o] Error 1
According to the Git log, it doesn't come from the toolchains but maybe from some changes done Yesterday or the day before...
Though, I can't go on :-(

EDIT :
Meanwhile, I try to follow the tracks manuallly, and I can see in duktape.h this :

Code: [Select]

DUK_EXTERNAL_DECL
duk_context *duk_create_heap(duk_alloc_function alloc_func,
                             duk_realloc_function realloc_func,
                             duk_free_function free_func,
                             void *heap_udata,
                             duk_fatal_function fatal_handler);
DUK_EXTERNAL_DECL void duk_destroy_heap(duk_context *ctx);

#define duk_create_heap_default() \
duk_create_heap(NULL, NULL, NULL, NULL, NULL)
Could the default duk_create_heap cause this issue ?

EDIT 2 :
I've just thought about this : NetSurf has RAM issues/leaks without DukTape, and it seems DukTape has this issue too. So maybe when we combine the RAM issues of both NetSurf and DukTape, the leak is so high that NetSurf is crashing before its launch. Without DukTape, NetSurf can be launched, but at a moment, it says "not enough memory". So maybe be focused only on DukTape memory leak isn't the best solution, is it ?

EDIT 3 (#ILoveEditingMyself) :
Is it normal than in dukky.c the "duk_create_heap" function called isn't a pointer while in duktape.c/duktape.h, "duk_create_heap" is defined as a pointer ("*duk_create_heap") ? Maybe the issue comes from there ! I think we need a * in dukky.c .

[DNADNL]

The output immediately prior to that might be more useful.

If i understood well, here is the steps before the issue (see the txt file enclosed).

I've not seen the leak that bad, in fact I'm not sure it's leaking so much as overwriting memory it shouldn't be.

Maybe we need to run something like MemGuard (but an OS3 equivalent, so MuGuardianAngel probably) and see where it crashes?

I did have a problem involving lists in an early version with memory being overwritten only on OS3.  I suspect the current problem is somewhat similar.

I think you're right that it is the combined effects, because NetSurf alone works, and Duktape alone works.

Yes, so either it's the link between them which doesn't work or when there are combined, they leak too much memory... or maybe both.

The * is part of the return type - it returns a pointer.  No star required when calling the function.

OK, I preferred to ask than to stay ignorant ! ^^

[DNADNL]

OK, here is the compilation issue, more specifically :

Code: [Select]

content/handlers/javascript/duktape/dukky.c:580: error: syntax error before "if"

OK, that comes from the file I use to replace dukky.c, sorry ! XD