duktape error NetSurf OS3

[chris]

Wich makes me wonder would render.library support HAM?

It does, as does guigfx, but I don't know how/if NetSurf would handle it.

[chris]

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

Almost certainly related to the horrid text layout routines which always cause me problems.

Please feel free to fix them.

[chris]

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.

Did the printf()s not print anything?

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

[chris]

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

OK, the LOG()s will print when you run "NetSurf -v". I've already done that

[chris]

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 ?

Probably, yes.

[chris]

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 ?

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.

[chris]

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?

[chris]

Sorry, we can't see anything in your attached thumbnail.

Yes, I know, that's why I typed out the relevant bit.

I'll go on the LOG way to see if it brings me to the same part of the code.

Good plan.

[chris]

If clib/clib2 are trashing memory also with ducktape, there is three options :

1. Get support from Olsen as he is maintainer of clib. He has already hinted to his will to help.
2. Compile it against libnix like wawrzon suggested. Wich could be usefull test anyway? Of course depending how much additional work it would cause?
3. Write own memory system to Netsurf / Ducktape.

1. That is the intention once I have enough information to sensibly report the problem.
2. Hassle, but might be necessary to (dis)prove the cause.
3. Unlikely to fix this particular problem.

[chris]

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

The output immediately prior to that might be more useful.

Could the default duk_create_heap cause this issue ?

No.  I tried reverting to the default one and the result was the same (unsurprising, given the replacement functions are more robust versions).

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 ?

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.

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 .

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

[chris]

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

Code: [Select]

content/handlers/javascript/duktape/dukky.c: In function `js_newcontext':
content/handlers/javascript/duktape/dukky.c:580: error: syntax error before "if"


Have a look at line 580 in content/handlers/javascript/duktape/dukky.c.  There's something odd before the "if".  Usually it means there's no semicolon at the end of line 579!

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.

Yep.

[chris]

Is it normal this part of code is in a do while loop with the condition (0) ?
[...]
EDIT : It seems there are two DUK_INTERNAL void duk_hthread_create_builtin_objects(duk_hthread *thr) functins in duktape.c . Is it normal ?

If you haven't changed it, yes.

[chris]

HEY, I'VE FOUND SOMETHING !
As I can see, there is a unending loop in duktape.c ! Yahoo !

Are you sure it is looping?  With my much reduced logging it took ages for NetSurf to start up.  I'd expect the looping to stop and the fatal error to print eventually.

[chris]

I'm not totally sure, but I can see that, when I launch a NetSurf version without duktape.c totally LOGged, The FATAL 56 appears in 3 seconds approx. , and when I launch the totally LOGged one, It takes approx 300 seconds to appear, and the issue doesn't apprear before.
I think it could be good to have a look at this function.

EDIT : I correct, with the totally LOGged version it doesn't stop. I think I unintentionnaly stopped it when I took a screenshot.
EDIT 2 : I correct again, with the totally LOGged version, it stops whenever it wants ! ^^

I don't really understand, but maybe you can log the variables in that function so we can get a clearer idea of what it is doing?

[chris]

I can give a try, we don't ever know. ^^ How do I do with LOG to display a variable ?

Same as printf, eg:
LOG("Var: %d, String: %s, Ptr: %p", var, string, ptr);
The %d might need to be %ld.  It's usually worth just using %ld anyway, although gcc tends to complain about it.

[chris]

So that could mean either the problem comes from
duk_js_compile() : safe_rc = duk_safe_call(ctx, duk__js_compile_raw, 2 /*nargs*/, 1 /*nret*/);
OR from
duk_js_compile() : if (safe_rc != DUK_EXEC_SUCCESS) : duk_throw(ctx);

duk_throw is the function which triggers the fatal, which means duk_safe_call is returning something other than DUK_EXEC_SUCCESS.

It would be useful to know:
(a) what duk_safe_call is actually returning.
(b) to find out where in duk_safe_call it is returning the error.