duktape error NetSurf OS3

[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 ?

[wawrzon]

@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.

[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.

[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... ^^

[wawrzon]

@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.

[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 ! ^^

[wawrzon]

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..

[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?

[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.

[utri007]

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.

[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.

[wawrzon]

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.

ad2. i would first link against bernds ixemul6x.x. this lib will almost certainly contain all linux functions you might miss with libnix. especially that arturs netsurf can be built with both ixemul and libnix. after all, its only frontend that differs, and why would reaction fronend depend on anything more linux than an sdl port? so it shouldnt be that much hassle in the final analysys.

ad3. you might rip the memory allocator out of the bernds ixemul..

[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 .

[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.