-
-
I'm using the exact example here on port 3030 to create a websocket server on an esp32 and when I attempt to connect to the server via a Chrome browser client I receive the error below:
The js code used in Chrome is extremely simple:
new WebSocket('ws://192.168.4.1:3030')
The weird part is the callback for when a websocket connection opens is called on the espruino websocket server:
server.on('websocket', function(ws){ console.log('websocket opened!'); });
but right after, Chrome throws the error shown in the image above, and I'm not able to send or receive messages.
The current espruino version info is:
{ VERSION: "2v00.42", GIT_COMMIT: "1a1fd36", BOARD: "ESP32", FLASH: 0, RAM: 524288, CONSOLE: "Serial1", EXPTR: 1073483756 }
Thank you in advance!
-
@Gordon you are awesome. I am unbelievably grateful that you jumped on this bug so quickly. I will try out the latest build later on tonight. Thank you again everyone!
-
I don’t think I explained myself well enough in my last post above. My apologies.
Every call I make to E.openFile is always followed by an f.close. This works consistently, until a call to E.openFile returns undefined, and i can no longer open and close files, respectively. The above example is explicitly showing the product of this - after running E.openFile, nothing is opened, i.e. undefined is returned (The 3rd-4th lines of the last image demonstrates the execution of the var f, and shows that undefined was assigned to it instead of a file object). Again, I open and close files sequentially, every time I open a file that actually returns a file object, I close right after.
I hope that explains it better. As for the process.memory().free call, I am very grateful you found that work-around! I just hope I can find out why, after opening and closing a file multiple times, and making sure every file I open is indeed closed directly after, eventually causes E.openFile to no longer return anything.
I think the first step in determining why the returned undefined value occurs is to explicitly throw an Out Of Memory error in the C code on the line of code that you’ve provided so it can much more easily be determined that we are simply out of memory vs some other underlying issue:
http://microcosm.app/out/tGLJh
Or, we should make E.openFile configurable in order to enable error throwing when we are out of memory. Again, this will allow developers to choose how to handle and discern whether or not a give api function isn’t working correctly because of lack of memory, or a different bug.
I’d love to hear your thoughts on this, because it wouldn’t cause a lot (if any) of overhead and it gives the developer the choice of how they want to deal with Out Of Memory issues, whether it be via an undefined return value (like it currently does) or an actual thrown error.
Thank you again @Wilberforce!!
-
@Wilberforce that is a solid work-around for now! I am able to execute write operations slightly more predictably now. But disappointingly, the ability to E.openFile still seems to lock up and return undefined after multiple read and write operations:
If I can overcome this last lockup issue that would be excellent! Thank you again!
-
Thank you again for your attempt at mitigating the bug that I am facing. There are a few things I would like to cover regarding the code that you've provided, but it's important to note upfront that your changes still result in the same error that I am facing, so I would definitely call it a bug at this point.
First off, your code has an unrecoverable syntax error on line 13:
This was an easy fix, just had to find the syntax issue.
Secondly, accessing a property on an object, regardless if it's global or not, does not need to be accessed via bracket notation just because it has a number at the end, so this may mislead someone to think this makes a difference stumbling upon this issue:
Like you stated, writing anything like the following is not idiomatic javascript, and as you stated, the code involves a security risk if there is anything interpolated into the string in the first argument (because it uses eval under the hood), so I wouldn't do this either (but for the purposes of finding this fs related bug, I will leave it for now):
Without further ado, Here is a screenshot of the resulting syntactically correct code randomly failing to write 14 / 100 files:
I think the most frustrating part is that this issue occurs on both writes and reads (When reading, somethings undefined is returned even though using fs.statSync showns that the file exists and has length).
Touching upon your other statement:
I never stated that fs has a open or close function:
I was stating that I had also attempted an alternative way of writing a file, specifically the functionality below that I did not post originally, because I had stated that "The same problems occur" intermittently:
var file = E.openFile('test_f', 'w'); file.write("wrote data"); file.close();
Thank you again for all your help. I do not think there is any solution to this bug without looking under the hood, so I will file an issue on the github repo and then start digging.
I have written error handling code that retries writing on error, but even then, sometimes it completely stops allowing me from writing to any file what-so-ever, until I execute a full reboot (which won't work in my control flow). So In the end, I think I'm going to have to look at the C code to see if there is anything suspicious occurring.
-
I am emphasizing that I am writing to a brand new file, I’ve tried all three possible ways of uploading, including uploading via console, uploading via the Upload button, as well as uploading via the Espruino command line tool, there are no other ways to upload. I’ve even wrapped the above code in an anonomyous function and executed, even with a setTimout to allow ANY other running scripts to load.
I think @Gordon should give his opinion. If he thinks This is developer error, I will gladly continue to debug. I’ve reached a point where the only thing left for me to do is post on the forum, which I will always hold out as long as possible to do. but I’ve reached a point where i’ve narrowed down the problem and provided a example script that demonstrates the issue consistently.
If you feel like this is still developer error, please let me know, and I will forgo the above conversation and move to a different library. Again, thank you for your help.
Also, the first device I began tinkering with was an Espruino board because I wanted to support @Gordon ‘s work, because I know how hard he’s worked on this.
-
I could take another screen shot of this happening using the upload button instead of copy and paste, but this snippet is really just an example of the problem happening in a much, much larger set of modules that I upload to the board.
I was able to narrow down the problem to this section of my code, then made the most base-case example of the problem occurring (as shown in the screenshot) then I ensured it was the problem by running it via:
- the IDE console,
- the Upload button via the right side of the IDE,
- using the Espruino js api tool (which is mainly what I use so I can use es6 and my own watch/compile/upload-only-changes-modules command line tool).
This issue happens in all three cases.
Thank you for the quick reply btw!
- the IDE console,
-
First off, thank you to everyone who has contributed to the espruino project, I love it.
I'm running into an issue using an esp32 where, after multiple calls to fs.readFile / fs.writeFile, E.openFile starts returning undefined, and both fs.readFile / fs.writeFile start returning false. Below is an example of fs.writeFile returning false after only 10 writes:
E.srand(4546455454545454); var fs = require('fs'); function writeData(i){ if(i < 100){ var data = Math.random().toString(); var name = `file_${i}`; var res = fs.writeFile(name, data); if(res){ console.log(`wrote... ${name}, ${data}`); setTimeout(function(){ writeData(i + 1); }, 100); } else{ console.log(`did not write!, ${name}, ${data}`); } } } writeData(0);
I don't think there are any js functions exposed to inspect the situation that is causing this, but please let me know if there is. Also, I'm using a setTimeout above so I don't hit the watchdog timeout, basically simulating if I typed this into the espruino IDE 9 times. below is version information:
{ "VERSION": "2v00", "GIT_COMMIT": "ff35517", "BOARD": "ESP32", "FLASH": 0, "RAM": 524288, "SERIAL": "240ac4af-68e4", "CONSOLE": "Serial1", "MODULES": "Flash,Storage,heatshrink,fs,net,dgram,tls,http,NetworkJS,Wifi,TelnetServer,crypto,neopixel", "EXPTR": 1073483756 }
Also, I've tried variations of this with E.openFile thinking that I could circumvent the issue but the same problem occurs.
Thank you in advanced for the help!!
There has been a problem with wifi for all versions following espruino_2v00.42 (due to espressif's SDK 3.1) . Feel free to follow along here https://github.com/espruino/Espruino/issues/1571. I don't think a stable wifi release has been cut yet, as I just tried the latest and I'm seeing the same results. @Wilberforce and @JumJum have been making good progress though!