Running Espruino on Win10 WSL?

[espruino-discuss]

Posted at 2018-10-24 by ryan42

Hi,

I was wondering if anyone has tried to compile Espruino on Windows Subsystem for Linux?

I have a few long flights from Europe back to Australia and I thought it would be great to be able to continue testing some things I'm working on for my Picos but on Windows 10? I should have bought a Pico with me and then I could just use that but only thought about this project while I have been away.

So far I have got Debian installed with WSL. I have installed all the required build tools, cloned from git and then make. Everything looks ok. Then I try run Espruino and I get the following...

Interactive mode.
Size of JsVar is now 32 bytes
Size of JsVarRef is now 4 bytes
Added SIGINT hook
Added SIGHUP hook
Added SIGTERM hook
ASSERT(strlen(name)<=8) FAILED AT src/jsflash.c:56
  #1[r1,l2] Object {
    #2[r1,l2] Name String [1 blocks] "\xFF"      #3[r1,l1] Object {
        #6[r1,l2] Name String [1 blocks] "timers"          #7[r2,l0] Array(0) [ ]
        #8[r1,l2] Name String [1 blocks] "watches"          #9[r2,l0] Array(0) [ ]
      }
  }
EXITING.

I had a look at jsflash.c but I'll admit its a bit over my head.

Anybody else tried this? Is it even possible?

Cheers
Ryan

[espruino-discuss]

Posted at 2018-10-24 by @gfwilliams

So you compiled this to run natively on WSL? Basically just running make?

It definitely should work - pretty sure I've done it before. Any chance you could run:

gdb espruino
s (for start)
c (for continue)
(it should now break at the assertion)
bt (backtrace - and paste up what it says)
q (quit)

That should tell us exactly which bit of code tried to access a file with a name that was too long.

---

Posted at 2018-10-24 by ryan42

Hi Gordon,

Thanks for that. See below. I had to run bt before continue as seemed to exit and provide no info, only No stack. Hopefully this is what you're after.

(gdb) start
Temporary breakpoint 2 at 0x806abc7: file targets/linux/main.c, line 252.
Starting program: /usr/local/bin/espruino
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 2, main (argc=1, argv=0x7ffffffde3a8) at targets/linux/main.c:252
252       int i, args = 0;
(gdb) bt
#0  main (argc=1, argv=0x7ffffffde3a8) at targets/linux/main.c:252
(gdb) continue
Continuing.
Interactive mode.
Size of JsVar is now 32 bytes
Size of JsVarRef is now 4 bytes
Added SIGINT hook
Added SIGHUP hook
Added SIGTERM hook
[New Thread 0x7ffffe570700 (LWP 12967)]
ASSERT(strlen(name)<=8) FAILED AT src/jsflash.c:56
  #1[r1,l2] Object {
    #2[r1,l2] Name String [1 blocks] "\xFF"      #3[r1,l1] Object {
        #6[r1,l2] Name String [1 blocks] "timers"          #7[r2,l0] Array(0) [ ]
        #8[r1,l2] Name String [1 blocks] "watches"          #9[r2,l0] Array(0) [ ]
      }
  }
EXITING.
[Thread 0x7fffff7b0740 (LWP 12966) exited]
[Inferior 1 (process 12966) exited with code 01]
(gdb) q

Cheers

---

Posted at 2018-10-25 by @gfwilliams

Ahh, ok - can you try it again, but with break jsAssertFail after s but before c - it should then stop on the assertion itself and you can backtrace it.

---

Posted at 2018-10-25 by jbgagnon

I don't know if it is the same problem, or this could help
but I compile on windows 7 (not 10 WSL) the ESP32 version
I flash it on an esp32 board.
I can make some test
but I can't use the reset() function because I have :

>reset()
=undefined
WARNING: Scan stop failed
WARNING: set rssi scan not implemeted yet
ASSERT(strlen(name)<=8) FAILED AT src/jsflash.c:56
  #1[r1,l2] Object {
    #2[r1,l2] Name String [1 blocks] "\xFF"      #3[r1,l1] Object {
        #6[r1,l2] Name String [2 blocks] "timers"          #8[r2,l0] Array(0) [ ]
        #9[r1,l2] Name String [2 blocks] "watches"          #11[r2,l0] Array(0) [ ]
        #14[r1,l2] Name String [1 blocks] "net"          #12[r1,l1] String [2 blocks] "\x05\x00\x00\x00\x00\xFF\xFF\xFF\x00\x00\x00\x00"
      }
  }
HALTING.

it look's similar no ?

---

Posted at 2018-10-25 by jbgagnon

well after modifying

JsfFileName jsfNameFromString(const char *name) {
  jsiConsolePrintf("jsfNameFromString [%s]%d\n",name, strlen(name));
  assert(strlen(name)<=8);

at boot I have :

ets Jun  8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:2364
load:0x40078000,len:0
load:0x40078000,len:10880
entry 0x40078c4c
jsfNameFromString [.varimg]7
jsfNameFromString [.bootcde]8
jsfNameFromString [.bootrst]8
jsfNameFromString [.boot0ý?]8
jsfNameFromString [.boot1ý?]8
jsfNameFromString [.boot2ý?]8
jsfNameFromString [.boot3ý?]8
jsfNameFromString [.bootrst]8
jsfNameFromString [.bootcde]8

and after reset() I have :

>reset()
=undefined
WARNING: Scan stop failed
WARNING: set rssi scan not implemeted yet
jsfNameFromString [.boot0ý?�]9

so the problem is of '\0' not well placed

---

Posted at 2018-10-25 by jbgagnon

bool jsfLoadBootCodeFromFlash(bool isReset) {
  // Load code in .boot0/1/2/3
  char filename[6] = ".bootX";
  for (int i=0;i<4;i++) {

filename 6 no place for '\0' it's a bug ?

---

Posted at 2018-10-25 by jbgagnon

changing 6 by 7

bool jsfLoadBootCodeFromFlash(bool isReset) {
  // Load code in .boot0/1/2/3
  char filename[7] = ".bootX";

no more problem everything is ok know

@ryan42 can you do the same change ?

(One good point for this stupid windows : it detects some bugs ...)

---

Posted at 2018-10-25 by @gfwilliams

Thanks! I just added that change to GitHub so if you pull now it should work.

That's really handy - I guess on most platforms it aligns the stack to the nearest 4 bytes, so it never got noticed.

---

Posted at 2018-10-25 by ryan42

Hi jbgagnon,

Yes that did it! Thanks for that.

@gfwilliams I do have that backtrace if you’d like it but I guess it’s all good?

Now for a 14 hour flight back to Australia, at least I can keep myself entertained.

Cheers!

---

Posted at 2018-10-26 by @gfwilliams

I do have that backtrace if you’d like it

It would have been helpful, but @jbgagnon beat us to it and fixed the problem - so we're fine now :)