duktape error NetSurf OS3

[DNADNL]

OK, I go on LOGging everything, but I can see I'm LOGging the error functions. So, I think I've put tracks on the way to obtain the issue. Here is the code :

Code: [Select]

(525.303815) duk_js_compiler.c:7791 duk_js_compile: duk_js_compile() : comp_stk.comp_ctx_alloc.lex.input_length = src_length;
(525.341080) duk_js_compiler.c:7794 duk_js_compile: duk_js_compile() : duk_push_pointer(ctx, (void *) &comp_stk);
(525.377255) duk_js_compiler.c:7799 duk_js_compile: duk_js_compile() : prev_ctx = thr->compile_ctx;
(525.413752) duk_js_compiler.c:7801 duk_js_compile: duk_js_compile() : thr->compile_ctx = &comp_stk.comp_ctx_alloc;
(525.449799) duk_js_compiler.c:7803 duk_js_compile: duk_js_compile() : safe_rc = duk_safe_call(ctx, duk__js_compile_raw, 2 /*nargs*/, 1 /*nret*/);
(525.504379) duk_error_longjmp.c:9 duk_err_longjmp: duk_err_longjmp() BEGIN
(525.549729) duk_error_longjmp.c:10 duk_err_longjmp: duk_err_longjmp() : DUK_ASSERT(thr != NULL);
(525.584814) duk_error_longjmp.c:13 duk_err_longjmp: duk_err_longjmp() : DUK_DD(DUK_DDPRINT(longjmp error: type=290914608 iserror=315533536 value1=!T value2=!T, (int) thr->heap->lj.type, (int) thr->heap->lj.iserror, &thr->heap->lj.value1, &thr->heap->lj.value2));
(525.643888) duk_error_longjmp.c:27 duk_err_longjmp: duk_err_longjmp() : if (!thr->heap->lj.jmpbuf_ptr) BEGIN
(525.679870) duk_error_longjmp.c:40 duk_err_longjmp: duk_err_longjmp() : if (!thr->heap->lj.jmpbuf_ptr) END
(525.714571) duk_error_longjmp.c:51 duk_err_longjmp: duk_err_longjmp() : DUK_LONGJMP(thr->heap->lj.jmpbuf_ptr->jb);
(525.750039) duk_js_compiler.c:7805 duk_js_compile: duk_js_compile() : thr->compile_ctx = prev_ctx;
(525.784035) duk_js_compiler.c:7808 duk_js_compile: duk_js_compile() : if (safe_rc != DUK_EXEC_SUCCESS) BEGIN
(525.817388) duk_js_compiler.c:7810 duk_js_compile: duk_js_compile() : if (safe_rc != DUK_EXEC_SUCCESS) : duk_throw(ctx);
(525.852152) duk_api_stack.c:4309 duk_throw: duk_throw() BEGIN
(525.880117) duk_api_stack.c:4310 duk_throw: duk_throw() : duk_hthread *thr = (duk_hthread *) ctx;
(525.911546) duk_api_stack.c:4313 duk_throw: duk_throw() : DUK_ASSERT(thr->valstack_bottom >= thr->valstack);
(525.944771) duk_api_stack.c:4315 duk_throw: duk_throw() : DUK_ASSERT(thr->valstack_top >= thr->valstack_bottom);
(525.977932) duk_api_stack.c:4317 duk_throw: duk_throw() : DUK_ASSERT(thr->valstack_end >= thr->valstack_top);
(526.009874) duk_api_stack.c:4320 duk_throw: duk_throw() : if (thr->valstack_top == thr->valstack_bottom) BEGIN
(526.044699) duk_api_stack.c:4325 duk_throw: duk_throw() : if (thr->valstack_top == thr->valstack_bottom) END
(526.078504) duk_api_stack.c:4336 duk_throw: duk_throw() : duk_hthread_sync_and_null_currpc(thr);
(526.110254) duk_api_stack.c:4340 duk_throw: duk_throw() : DUK_DDD(DUK_DDDPRINT(THROW ERROR (API): !dT (before throw augment), (duk_tval *) duk_get_tval(ctx, -1)));
(526.147969) duk_api_stack.c:4342 duk_throw: duk_throw() : duk_err_augment_error_throw(thr);
(526.182220) duk_api_stack.c:4345 duk_throw: duk_throw() : DUK_DDD(DUK_DDDPRINT(THROW ERROR (API): !dT (after throw augment), (duk_tval *) duk_get_tval(ctx, -1)));
(526.219230) duk_api_stack.c:4348 duk_throw: duk_throw() : duk_err_setup_heap_ljstate(thr, DUK_LJ_TYPE_THROW);
(526.253096) duk_api_stack.c:4356 duk_throw: duk_throw() : duk_err_longjmp(thr);
(526.283755) duk_error_longjmp.c:9 duk_err_longjmp: duk_err_longjmp() BEGIN
(526.312810) duk_error_longjmp.c:10 duk_err_longjmp: duk_err_longjmp() : DUK_ASSERT(thr != NULL);
(526.344496) duk_error_longjmp.c:13 duk_err_longjmp: duk_err_longjmp() : DUK_DD(DUK_DDPRINT(longjmp error: type=290914608 iserror=315598072 value1=!T value2=!T, (int) thr->heap->lj.type, (int) thr->heap->lj.iserror, &thr->heap->lj.value1, &thr->heap->lj.value2));
(526.397541) duk_error_longjmp.c:27 duk_err_longjmp: duk_err_longjmp() : if (!thr->heap->lj.jmpbuf_ptr) BEGIN
(526.433121) duk_error_longjmp.c:30 duk_err_longjmp: duk_err_longjmp() : if (!thr->heap->lj.jmpbuf_ptr) : DUK_D(DUK_DPRINT(uncaught error: type=290914608 iserror=315598072 value1=!T value2=!T, (int) thr->heap->lj.type, (int) thr->heap->lj.iserror, &thr->heap->lj.value1,
 &thr->heap->lj.value2));
(526.505425) duk_error_longjmp.c:35 duk_err_longjmp: duk_err_longjmp() : if (!thr->heap->lj.jmpbuf_ptr) : duk_fatal((duk_context *) thr, DUK_ERR_UNCAUGHT_ERROR, uncaught error);
FATAL 56: uncaught error
PANIC 56: uncaught error (calling abort)
Abnormal program termination
NetSurf : erreur code 20
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);

But now I don't know how to be sure about that...

EDIT : I can't go further for the LOGs, so I think the Issue is there.

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

[DNADNL]

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.

OK. We worked on this with Tygre yesterday. We saw the problem could be in

Code: [Select]

DUK_LOCAL duk_ret_t duk__js_compile_raw(duk_context *ctx).
I'm going to check this out.

[DNADNL]

OK, I reached the same part of code than you, chris :

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);
}

With Tygre, we climbed back up to this line (in duktape.c : duk__parse_func_like_fnum() ) :

Code: [Select]

duk__advance_expect(comp_ctx, DUK_TOK_RCURLY);
We think the JavaScript code used to test duktape during the NetSurf launch is responsible of the issue. Is it possible to know what is the JavaScript code executed during the NetSurf launch ? (we thought first that the NetSurf Welcome page executed Javascript code to explain the issue, but that's not the case).

However, it's quite disappointing and not handy if NetSurf crashes only because a JavaScript test script...

[utri007]

Just quick question :

People are testing these builds now in vampire irc chanel. Seems that DNADNL build from github has wrong colors and it is much slower than beta build in Chris' home page?

Why?

Haven't tested this myself, but seems reliable.

[freeaks]

@dnadnl,
i've just tested your build from github, i have to report: it is quite slower than chrisY's and the color are wrong too. (tested on uae, rtg)

@chrisY: your build is faster, color are good.
is there anychance you could release a nofpu build so vampire owner could use you netsurf port ?

fpu support for vampire is coming, but meanwhile there's a good number of users that cannot run your build of netsurf and would like to play with it a lot

myself too i ordered a vampire so, there is interest for your 68k port of netsurf, thanks for doing it!

[DNADNL]

@dnadnl,
i've just tested your build from github, i have to report: it is quite slower than chrisY's and the color are wrong too. (tested on uae, rtg)

@chrisY: your build is faster, color are good.
is there anychance you could release a nofpu build so vampire owner could use you netsurf port ?

fpu support for vampire is coming, but meanwhile there's a good number of users that cannot run your build of netsurf and would like to play with it a lot

myself too i ordered a vampire so, there is interest for your 68k port of netsurf, thanks for doing it!

As I said before and in the README (if I recall well), the NetSurf AmigaOS3 version on my GitHub isn't updated every day, so some changes are not included in (that's the case for the images). But I'll compile it again, now.

[chris]

@chrisY: your build is faster, color are good.
is there anychance you could release a nofpu build so vampire owner could use you netsurf port ?

Are you sure the current build (test build on cy2, not the Aminet one) isn't working?

[chris]

OK, I reached the same part of code than you, chris :

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);
}


With Tygre, we climbed back up to this line (in duktape.c : duk__parse_func_like_fnum() ) :

Code: [Select]


duk__advance_expect(comp_ctx, DUK_TOK_RCURLY);

We think the JavaScript code used to test duktape during the NetSurf launch is responsible of the issue. Is it possible to know what is the JavaScript code executed during the NetSurf launch ? (we thought first that the NetSurf Welcome page executed Javascript code to explain the issue, but that's not the case).

However, it's quite disappointing and not handy if NetSurf crashes only because a JavaScript test script...

AFAIK it doesn't run any tests on startup.  Might be a question for the netsurf-dev mailing list (or IRC).

[DNADNL]

AFAIK it doesn't run any tests on startup.  Might be a question for the netsurf-dev mailing list (or IRC).

I don't know how to find this IRC, so maybe I'll let you ask the question ! ^^

[utri007]

As I said before and in the README (if I recall well), the NetSurf AmigaOS3 version on my GitHub isn't updated every day, so some changes are not included in (that's the case for the images). But I'll compile it again, now.

I don't know how old compile Chris' version is, but there shouldn't be a big diffrence? Could you compile it like apj hinted?

my version with -m68020 and this works without fpu too.
(-m68020-60 doesn't).

That would make many Vampire FPGA accelerator users happy

[freeaks]

@dnadnl: thanks for building a new version

@chris: i don't have my vampire yet, it's on the road, being delivered to me. meanwhile i'm testing with uae. i'll check with the other vampire owners if they can run your last beta build as you say they should be  able to. if so then good news

[DNADNL]

@utri007 & @freeaks OK, the NetSurf Archive available in my GitHub is now whole new fresh (without DukTape) ! ^^ You can test it if you want.

[utri007]

Are you sure the current build (test build on cy2, not the Aminet one) isn't working?

I'm 99% sure that freeaks talks version here : http://www.unsatisfactorysoftware.co.uk/index.php?pg=netsurf

At least he said so in irc

[chris]

I'm 99% sure that freeaks talks version here : http://www.unsatisfactorysoftware.co.uk/index.php?pg=netsurf

At least he said so in irc

That page links to both builds!
The "test build" is built with -m68020
The Aminet build probably isn't.

[chris]

I don't know how to find this IRC, so maybe I'll let you ask the question ! ^^

http://www.netsurf-browser.org/contact/