I run go build in the $GOPATH of my arch Vagrant box.
But it prints out
runtime: panic before malloc heap initialized
fatal error: runtime: cannot allocate heap metadata
And the box is 3.10.9-1-ARCH x86_64, memory 242M.
Why I can't build go files in the box?
Thanks in advance.
Looks like this is caused by not enough virtual memory
$ ulimit -v 242000
$ go build prog.go
runtime: panic before malloc heap initialized
fatal error: runtime: cannot allocate heap metadata
64bit go needs lots of virtual memory space but not necessarily that much real memory.
You could fix this by allocating more memory to the container.
You could also play with the setting of /proc/sys/vm/overcommit_memory.
You could also try allocating swap to the container (if possible).
Related
When trying to deploy my application with Serverless Framework using the properties:
package:
individually: true
i got the follow error:
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
My NodeJS version is 10..
Some people said to enhance the NodeJS memory with the code:
export NODE_OPTIONS="--max-old-space-size=8192"
But i had no happy result.
I just ended up this error installing a newer version of NodeJS. In my case v14.15.4
node version: 8.10.0
npm -v: 5.6.0
system: mac
on running npm run build, system throws following error
67% building modules 2081/2181 modules 100 active
...ent/completed-shipment.component.scssng(85928,0x70000312e000)
malloc: *** error for object 0x1023e9fd0: pointer being freed was not
allocated
Clearly this is because of css and probably related to variables/functions in css. But not sure where the issue lies. This was working clean 2 days earlier but started to fail now. Any known issues recently on node-sass/libsass?
I am debugging a compiled (c++) python module which mysteriously crashes at import time inside docker container. When I run python3 inside gdb, then import, and then try to print backtrace, I only get
# gdb /usr/bin/pyton3
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.
...
(gdb) run -c 'import myModule'
warning: Error disabling address space randomization: Operation not permitted
During startup program terminated with signal SIGSEGV, Segmentation fault.
(gdb) bt
No stack.
(gdb)
Are there some restriction what gdb can(not) do inside a Docker container? The crash in itself is surprising, but the inability to debug it even more so. The module is compiled with -ggdb2 to include as much debugging information as possible.
For the record: debugging (and also strace) need the CAP_PTRACE capability. The problem was solved by running the container with --privileged.
While trying to load a core file using dbx I get the following warning:
dbx: internal warning: writable memory segment 0xfa8b0000[16384] of size 0 in core
There doesn't seem to be an explanation in:
(dbx) help core
What does this message mean?
EDIT
The rest of the output:
core file header read successfully
Reading ld.so.1
dbx: internal error: signal SIGBUS (invalid address alignment)
dbx's coredump will appear in /tmp
Abort (core dumped)
And dbx exits without loading the core.
Got solved by upgrading Solaris Studio to version 12.3 and using the newer dbx from there.
One of the reasons why this could happen is because dbx expects the absolute path to get the object files, try giving the
dbx <PATHTOBINARY>/binaryfile
Of course, you can upgrade dbx to the latest version to fix the same.
I have problems with Ocropus 4.4. (open source OCR). I installed Ocropus and neccessary libries following this script. Compilation/Installation goes without any problem.
However after successful installation of ocropus, I am not able to run any of ocropus-* commands. Ocropus-page and ocropus-hocr crash without giving any error meaningful message. I just get a cryptic killed after 2 minutes of processing.
ocropus-pages page_001.jpeg
[note] line recognizer: >
[note] *** 1 page_001.jpeg ***
Killed
I do not know where to start to fix it. Has anybody an idea where to start?
My machine is XUbuntu 10.4 64bits (run in VirtualBox) with 512MB of base memory.
I would try to convert your images to uncrompressed tiff before processing. I know that ocropus is working closely with tesseract and that tesseract handles 1bpp uncompressed tiffs the best.
Despite this being an old question I thought I'd post a solution / some debug tips as I experienced the same problem under the same scenario. The scenario being: Debian running under VirtualBox with 512MB RAM
In order to debug "Killed" messages you should look into /var/log for help. In my case kern.log contained:
debian kernel: [89675.791910] Out of memory: Kill process 13004
(ocropus-rtrain) score 806 or sacrifice child
debian kernel: [89675.791951] Killed process 13004 (ocropus-rtrain)
total-vm:800816kB, anon-rss:412424kB, file-rss:4kB
It's likely you need to increase the amount of resources assigned to the VM particularly if you're running some big fancy window manager in the background!