Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Http client tries to alloc 1.3GiB of RAM #8

Closed
Spritetm opened this issue Jul 24, 2015 · 3 comments
Closed

Http client tries to alloc 1.3GiB of RAM #8

Spritetm opened this issue Jul 24, 2015 · 3 comments

Comments

@Spritetm
Copy link

I try to get some code up and running that fetches some JSON from a server and turns on or off a LED according to the retrieved value. This is my init.js:

Debug.mode(1)

function doStuff() {
    var url="http://meuk.spritesserver.nl/lighttest.php";
    Http.get(url, function(d, e) {
        print("doStuff http req done.");
        if(e) {
            print("Error: "+e);
        } else {
            print("Got "+d);
            res=eval(d);
            GPIO.write(2, res.led);
        }
        setTimeout(doStuff, 3000);
    });
    print("doStuff done.");
}

Wifi.setup("testjmd", "mypassword");
print("Call doStuff to kick off process");

If I now call doStuff(), instead of turning on or off the LED, the Smart.js interpreter traps on a malloc fail:

smartjs 7864/3072$ No heap available, failed to malloc 1394634784

Trap 9: pc=0x40100a2a va=0x726562
waiting for gdb

I'll leave the URL I called up, so you can do tests if you need to do so. I get this result both when the webserver returns a 404, as well as when it returns a small JSON file. FYI, this is the GDB backtrace when it retrieves a 404; I presume the effect on the JSON file is the same but I couldn't be bothered to attach GDB for that.

#0  0x40100a2a in ?? ()
#1  0x40100996 in vPortFree ()
#2  0x40100a11 in pvPortRealloc ()
#3  0x402214e8 in realloc (ptr=0x3fff9ca0, size=size@entry=887) at user/libc_replacements.c:52
#4  0x4022363f in mbuf_resize (a=a@entry=0x3fff4dc8, new_size=887) at user/v7.c:2411
#5  0x402236ec in mbuf_trim (mbuf=mbuf@entry=0x3fff4dc8) at user/v7.c:2419
#6  0x402266ca in v7_gc (v7=0x3fff4d68, full=<error reading variable: can't compute CFA for this frame>, 
    full@entry=1) at user/v7.c:8598
#7  0x402214f4 in realloc (ptr=0x3fff9ca0, size=1394634762) at user/libc_replacements.c:54
#8  0x4022374a in mbuf_insert (a=a@entry=0x3fff4dc8, off=off@entry=887, buf=buf@entry=0x0, 
    len=1394633875, len@entry=<error reading variable: can't compute CFA for this frame>)
    at user/v7.c:2438
#9  0x40226a48 in embed_string (m=m@entry=0x3fff4dc8, offset=887, 
    p=0x3fff97c7 "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /lighttest.php was not found on this server.</p>\n<hr>"..., len=len@entry=1394633869, 
    zero_term=<error reading variable: can't compute CFA for this frame>, zero_term@entry=1, 
    unesc=<error reading variable: can't compute CFA for this frame>, unesc@entry=0) at user/v7.c:7645
#10 0x40226b6c in v7_create_string (v7=0x3fff4d68, 
    p=<error reading variable: can't compute CFA for this frame>, 
    p@entry=0x3fff97c7 "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p>The requested URL /lighttest.php was not found on this server.</p>\n<hr>"..., len=1394633869, own=own@entry=1) at user/v7.c:7690
#11 0x40232150 in http_disconnect_cb (arg=<error reading variable: can't compute CFA for this frame>)
    at user/v7_http_client.c:115
#12 0x40251b1e in ?? ()
#13 0x40251b1e in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
@imax9000
Copy link
Contributor

Thanks for the report! I believe this is partially "fixed" by 68c871e

HTTP client is rather simplistic now :(

@cpq
Copy link
Member

cpq commented Jul 24, 2015

@Spritetm could you try again please? The "fix" was just increasing HTTP buffer size, I think it is going to work for you unless your JSON thing is huge.

Agree with @gelraen , our HTTP client is primitive at the moment. It uses native ESP SDK, which is not convenient. We're looking into possibility of using something that provides BSD sockets API (e.g. FreeRTOS based SDK), port Fossa (https://github.com/cesanta/fossa) over and provide JS bindings to Fossa. That would give rich networking ability to the firmware.

@cpq
Copy link
Member

cpq commented Jul 25, 2015

Closing this for now.
Please reopen if still an issue.

@cpq cpq closed this as completed Jul 25, 2015
@JamesHepworth JamesHepworth mentioned this issue Aug 27, 2018
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@cpq @imax9000 @Spritetm