Core dump when running script to get a file

I’m running a script file to get a file from a secure location. If I run the script from the command line, it works flawlessly. If I call it from my app, when it actually starts the download I get:
5616File size limit exceeded (core dumped).

I have raised the limits on my app for both the max File system bytes and max File bytes, to no avail. What is causing this issue?


How about turn-off sandboxing by setting sandboxed to false?

Already running that way. Plus the 5616 file size doesn’t correspond to any visible setting.


how about running the script in your app by system() API.

That IS what I’m doing. Not sure how I’d do it any other way. Sorry, should have been more specific.
I’m using the “system” call to run a shell script which is required to download the file. Everything is fine until it starts the download, then I get the message shown in my first post.

A bit confused…
What is the meaning of “Everything is fine until it starts the download, then I get the message shown in my first post.”?
What is the message shown in your first post?

HI @jyijyi,
What I mean is the script runs fine until it starts the download. All the hands shakes and security protocols go fine, then it starts the download and I get this message:

5616File size limit exceeded (core dumped).

That’s like 5.6KBytes. Not very much.
I can run the script from the command line and it works fine and downloads the file (just under 6 meg). I redirected standard output to a file to find out why it was failing.


How about you compile a simple hello world application with the toolchain like:

/home/owner/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc -o hello.arm.o hello.c

Inside the hello.c, you can call your script by system() API.

This experiment can isolate if your problem is only related to legato application.

That won’t work as I have a WP7601, but I get your point. I will try and get back to you.

I can’t get it to link. It can’t find the libs for some reason.

Hi @EvetsMostel
Legato apps sandboxes have by default a quite low limit for their temporary file system.
cf Application Definition .adef - Legato Docs

I’m not running this sandboxed. And I’ve changed the maxFileBytes to 10512K, or 10.5Meg. I’ve also changed the maxFileSystemBytes: to 10512K as well. Neither of these affected this problem.

I was able to get the program to link. Runs flawlessly, but again, I’m running it from a bash shell, which the script works without the exe calling it. However, if I launch the exe via Legato, then I get the same error, File size limit exceeded (core dumped). I’m downloading the file to /home/root, so there should be no legato filesize issue. Again, all the MaxFileSize and MaxSystemFileSize limits have been raised to 10.5Meg. I can successfully download the file via a connection from a web page served from this device. What setting do I need to “adjust” to get this to work?
I even tried running this in the background, but it still hits that limitation.

how about using the binary program hello.o to call your script by system() API?

I did. That’s what I was saying. But the effect is the same. If I run my binary program to call the script, I’m starting it from the command line and it works. If I call the same binary program from my legato app, it gives me the File size limit exceeded (core dumped) error.

Can you attach your script here so that we can reproduce the issue on MangoH green board?

No, because this is a public forum and for security measures it has keys in the script. But you can do it by creating an AWS S3 resource and putting a 6 Meg file there.

Here is the template script:
dateValue=date -R
signature=echo -en ${stringToSign} | openssl sha1 -hmac ${s3Secret} -binary | base64

curl -H “Host: ${bucket}”
-H “Date: ${dateValue}”
-H “Content-Type: ${contentType}”
-H “Authorization: AWS ${s3Key}:${signature}”
https://${bucket}${amzFile} -o $outputFile

You will need to compile base64 from the gnu coreutils as that isn’t included in the image. I used v8.25 since that matches the other things that are on Yocto.

I even went so far as to create a service which would start the binary created in the last exercise at boot (after everything), wait for an internet connection, then go get the file. However, I can’t seem to get it to automatically start for some reason. I can run it from the command line with /etc/init.d/ start, and that works. So I thought that I could run it from the Legato app that way, since I’m not actually starting it. However, I get the same issue, although the cutoff point seems to be slightly higher, but not much.

I tried on WP750x.
I put the test script here:

root@swi-mdm9x15:/tmp# cat /tmp/
curl -o /dev/null -k

After that I run a unsandboxed legato application:

#include “legato.h”

LE_INFO(“Hello, world.”);

No problem is found.
Would you please modify my script to reproduce the issue?

So, Not sure what to tell you since you are running on a different device. However, I did find these two things that allowed me to get it to work.

  1. R7, doesn’t work (17.11 Legato, WP7601) regardless of where you put it.
  2. R8 will work, but like you did in you script, it depends on where the file it going. I was using a relative path thinking it would be relative to the script, but in fact it was relative to where my app was in Legato. When I corrected that to put it where I wanted it, it worked fine, but again, it had to be R8 (18.1.0) for my device, WP7601.
    In that case, does the filesize set in Legato make any difference?

this is issue is solved.

Hi EvetsMostel
Have you solved this problem? I have the same problem