Ocropus 4.4. crashes on Xubuntu 10.4 - compilation

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!

Related

Tensorflow in Docker on MacOs cannot load libraries with the tensorflow/tensorflow:latest image

Following the Getting Started guide for running Tensorflow in a docker container yields an error very quickly. Working through the instructions here, I pulled the tensorflow/tensorflow:latest image and then tried running:
docker run -it --rm tensorflow/tensorflow:latest python -c "import tensorflow as tf; print(tf.reduce_sum(tf.random.normal([1000, 1000])))"
It's billed as a cpu-only image (under section https://www.tensorflow.org/install/docker#examples_using_cpu-only_images), which I believe I need because I'm running on a Mac, and don't have an Nvidia graphics card. However, the following errors occur:
~/> docker run -it --rm tensorflow/tensorflow:latest python -c "import tensorflow as tf; print(tf.reduce_sum(tf.random.normal([1000, 1000])))"
2020-01-12 18:53:17.848471: W tensorflow/stream_executor/platform/default/dso_loader.cc:55] Could not load dynamic library 'libnvinfer.so.6'; dlerror: libnvinfer.so.6: cannot open shared object file: No such file or directory
2020-01-12 18:53:17.848763: W tensorflow/stream_executor/platform/default/dso_loader.cc:55] Could not load dynamic library 'libnvinfer_plugin.so.6'; dlerror: libnvinfer_plugin.so.6: cannot open shared object file: No such file or directory
2020-01-12 18:53:17.848843: W tensorflow/compiler/tf2tensorrt/utils/py_utils.cc:30] Cannot dlopen some TensorRT libraries. If you would like to use Nvidia GPU with TensorRT, please make sure the missing libraries mentioned above are installed properly.
2020-01-12 18:53:18.288367: W tensorflow/stream_executor/platform/default/dso_loader.cc:55] Could not load dynamic library 'libcuda.so.1'; dlerror: libcuda.so.1: cannot open shared object file: No such file or directory
2020-01-12 18:53:18.288461: E tensorflow/stream_executor/cuda/cuda_driver.cc:351] failed call to cuInit: UNKNOWN ERROR (303)
2020-01-12 18:53:18.288516: I tensorflow/stream_executor/cuda/cuda_diagnostics.cc:156] kernel driver does not appear to be running on this host (996a2dd2ab59): /proc/driver/nvidia/version does not exist
2020-01-12 18:53:18.289117: I tensorflow/core/platform/cpu_feature_guard.cc:142] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2 FMA
2020-01-12 18:53:18.295734: I tensorflow/core/platform/profile_utils/cpu_utils.cc:94] CPU Frequency: 2592000000 Hz
2020-01-12 18:53:18.296844: I tensorflow/compiler/xla/service/service.cc:168] XLA service 0x55c37f5f81f0 initialized for platform Host (this does not guarantee that XLA will be used). Devices:
2020-01-12 18:53:18.296881: I tensorflow/compiler/xla/service/service.cc:176] StreamExecutor device (0): Host, Default Version
tf.Tensor(-203.31216, shape=(), dtype=float32)
Are the instructions misleading (saying latest is a cpu-only image) or am I missing something? I see references to cuda in the output so it would seem this isn't a cpu-only image? Should I be using a different image?
Here are my specs:
macOs Mojave - 10.14.6
Docker Desktop - 2.1.0.6
docker - 19.03.5
I had this same issue not long ago, but I discovered that it actually prints the correct result, and those logs might be warnings.
The result of print(tf.reduce_sum(tf.random.normal([1000, 1000]))) is actually tf.Tensor(-203.31216, shape=(), dtype=float32), which is in the last line of what was printed out.
if you can run your code in a jupyter notebook, then you should use the jupyter/tensorflow-notebook image.
Set it up this way:
docker pull jupyter/tensorflow-notebook
docker run -p 8888:8888 jupyter/tensorflow-notebook
After running the container, a link would be displayed on the terminal that you can use to access the notebook. Copy the link and paste in your browser, and start writing your code. It worked well for me without any of those "Warnings" printed out.
If the tensorflow container runs your code correctly with those errors still printed out, please let me know. But for now I am using the jupyter notebook container and I am not getting any errors or warnings.
If i find a way of clearing those warnings, I will let you know here.
I met this problem too, and I was trying to run on a PC. Because the nvidia-docker doesn't support Windows, I also have to use the cpu-only image.
As Odohi David said, you can run your code in a jupyter notebook. You may run it with the official image like this:
docker run -it -p 8888:8888 tensorflow/tensorflow:latest-py3-jupyter
Then open localhost:8888 in your browser. You will need a token to access the notebook and you can find it in the terminal. For example:
[I 13:57:13.801 NotebookApp] http://8c6f388f31c0:8888/?token=44ec1f209c1777c4c1b28b38b9842f297e170cbacf24b291
In this case, the token is 44ec1f209c1777c4c1b28b38b9842f297e170cbacf24b291.
After that, you can access to the official tensorflow-tutorials, and write your code on the notebook.

Freedos installation on Qemu fails with "unable to locate the installation packages"

Trying to install Freedos (v1.2) in Qemu - and it fails always with the same error: Unable to locate the installation packages..
On the web there are versions of the same guide on how to do this: https://opensource.com/article/17/10/run-dos-applications-linux
I can create the image for the hard drive, then run qemu:
qemu-system-i386 -m 16 -k en-us -rtc base=localtime -soundhw sb16,adlib -device cirrus-vga -cdrom FD12FULL/FD12FULL.img -hda freedos.img -boot order=d
The installation process starts successfully, it finds the hard drive images, then it formats it and mark as primary. Then I can select the language and start the installation - on the next screen it shows a dialogue to gather information about the machine - and the next screen is the failure:
I've tried the following options when starting qemu:
for cdrom using the "standard" / "legacy" / "full" / "lite" Freedos installation CD images
using both these 4 CD images with and without the official Freedos installation Floppy
booting from CD and booting from Floppy
attaching the CD img as img or as mounted drive
If I select No - Return to DOS I always see 3 drives: (A:) having the CD image, (B:) floppy image, (C:) the empty attached drive image and a (D:) drive which is not readable.
Looked at a few findings in google (case 1, case 2) but didn't really helped much.
seems to be a bug in seabios regarding support of ATA CDROMs, see https://patchwork.kernel.org/patch/10857581/ and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934134
In case anyone else is looking for an answer. The problem was due to a version of seabios that has a CD driver bug. If you download the latest version and compile it. You should be able to provide the "-bios <your_newer_compiled_seabios>" to the qemu command line to get around this problem.
What I did was follow these steps:
# Get a newer version of the seabios:
$ git clone https://git.seabios.org/seabios.git
# Change directory and compile it
$ cd seabios
$ make
...
Total size: 185536 Fixed: 87584 Free: 76608 (used 70.8% of 256KiB rom)
Creating out/bios.bin
Then I used the out/bios.bin bios in your qemu command line to load it:
$ <your-qemu-command-line> -bios out/bios.bin <any other command options>
Hope that helps other folks running into the same problem.

DB2 db2prereqcheck how to make it work?

I'm newbie in DB2 database administration and I couldn't think that I'd be stuck with the installation process. I read some documents before installation and found an interesting "db2prereqcheck" thing.
So I tried to run it before installation and got an error:
DBT3505E The db2prereqcheck utility was unable to determine the Linux distribution level.
About this error from ibm:
IBM Knowledge Center: DBT3505E
IBM Support: db2prereqcheck fails checking Linux distribution
I found some other answers where suggest to delete the files "/etc/issue" and "/etc/issue.net".
I checked my "/etc/issue*" files according to the tips. I filled that files with the example from the article in IBM Support, but nothing has changed. I tried running this script on other servers with CentOS, Debian operating systems, but got another error:
./db2prereqcheck
DBI1189E There has been an attempt to use db2prereqcheck
on an image for a platform that does not match the current platform
'Linux/x86-64' on which it is being run.
Explanation:
Possible causes include:
- This DB2 install image is not valid for the current
platform.
- The current platform is not supported by DB2.
User Response:
Install DB2 using the DB2 install image that corresponds
with the current platform 'Linux/x86-64'.
I've already installed db2, but my self-esteem is down. So the question is: my hands are a problem or is the problem in another? And how to make db2 work
Technical details:
cat /etc/issue
Amazon Linux AMI release 2018.03
Kernel \r on an \m
cat /etc/*-rel*
NAME="Amazon Linux AMI"
VERSION="2018.03"
ID="amzn"
ID_LIKE="rhel fedora"
VERSION_ID="2018.03"
PRETTY_NAME="Amazon Linux AMI 2018.03"
ANSI_COLOR="0;33"
CPE_NAME="cpe:/o:amazon:linux:2018.03:ga"
HOME_URL="http://aws.amazon.com/amazon-linux-ami/"
Amazon Linux AMI release 2018.03
cpe:/o:amazon:linux:2018.03:ga
uname -a
Linux hostname.host 4.14.47-56.37.amzn1.x86_64 #1 SMP Wed Jun 6 18:49:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
As you may have noticed, this is an EC2 instance.
DB2 versions:
IBM® Db2 11.1 Developer-C Edition for Linux® on AMD64 and Intel® EM64T systems (x64)
IBM® DB2 Express-C Version 11.1
I would appreciate your help in this matter. Thank you for your time.
If db2prereqcheck reports :
DBT3505E The db2prereqcheck utility was unable to determine the Linux
distribution level. Aborting the current installation ... Run
installation with the option "-f sysreq" parameter to force the
installation.
and if other IBM suggestions do not apply, then you may be able to avoid this symptom with the following workaround:
(as root)
cp /etc/os-release /etc/lsb-release
The reason it works is that some versions of db2prereqcheck look only for the following files in turn:
/etc/centos-release
/etc/redhat-release
/etc/SuSE-release
/etc/lsb-release
If none of those files are present, the DBT3505E symptom can result.
If your distro (or container) has an equivalent file (for example, Debian may have /etc/os-release) then simply copying it to /etc/lsb-release will allow db2prereqcheck to complete.
db2prereqcheck checks and understands only /etc/SuSE-release with the following content:
SUSE Linux Enterprise Server 15 (x86_64)
VERSION = 15
PATCHLEVEL= 1
This works also with OpenSuse Leap 15.1. This file is deprecated since SLES 12. So you must create it your self. Then run db2prereqcheck and install all missing libraries and kernel sources mentioned. Having all requirements fulfilled you may finally see the segmentation fault message:
Validating "Intel TCO WatchDog Timer Driver modules" ...
DBT3546E The db2prereqcheck utility failed to determine whether the
following file or package exists: "".
Segmentation fault (core dumped)
Don't worry!
Simply retest with db2prereqcheck -i. The -i parameter checks for prerequisites that are not Db2 pureScale related. If we don't install pureScale and all requirement are fulfilled, we can ignore this ugly segmentation fault.
Otherwise you must blacklist by adding:
blacklist iTCO_wdt
blacklist iTCO_vendor_support
Into the file /etc/modprobe.d/blacklist.conf
A further issue is related to:
export DISPLAY=your.machine.ip:0.0
running ./db2setup as root doesn't work.
./db2_install is deprecated, but it works.
First create the db2 users and groups as described by the IBM Knowledge Center.
Then run ./db2_install as root, followed by creating an instance using db2icrt.
Login as db2inst1 and test as described by the IBM Knowledge Center eventually creating the SAMPLE Database, etc. Normally "first steps" would do the job, but it crashes with javascript error. Hence you must do it manually!
Additional manual configuration may be required as opening the firewall for port 50001 and setting this port within /etc/services and within dbm cfg with:
db2 update dbm cfg using SVCENAME 50001
or
db2 update dbm cfg using SVCENAME db2c_db2inst1
If you use the latter you must update /etc/services with the line:
db2c_db2inst1 50001/tcp #and a comment like db2 tcp/ip
connection port.

Upstart causes kernel panic on embedded Linux

I am using ptxdist to create kernel and rootfs images for a Linux embedded system, running on an ARM Cortex A8 CPU.
I was trying to use a newer compiler (GCC 5+) and so was forced to upgrade several external packages that would not compile under the new GCC.
I compiled the following versions of Upstart and its immediate dependencies:
upstart: 1.13.2
libnih: 1.0.3
dbus: 1.11.2
json-c: 0.12.1
When I boot, I get the following message:
init: com.ubuntu.Upstart.c:3525: Assertion failed in control_emit_event_emitted: env != NULL
init: Caught abort, core dumped
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000600
Searching online did not yield useful hints - the only relevant issue I found is this, but it is relevant to an older version of Upstart, and my libnih is of the correct version already.
According to comment #8 in the bug report you linked, it is not enough to use version 1.0.3 of libnih -- you have to specifically use the Ubuntu version, as this seems to include dbus fixes which could solve the problem you are seeing. From the bug report:
David Ireland (e-david) wrote on 2013-04-22: #7
I've built libnih
1.0.3 from source and also made sure that upstart builds with that version of the nih-dbus-tool. I'm still having this problem.
James Hunt (jamesodhunt) wrote on 2013-04-22: #8
Which problem? The
crash? If so, you are still using the wrong version of libnih: you
should be using the Ubuntu version (specifically 1.0.3-4ubuntu16) from
here:
https://code.launchpad.net/~ubuntu-branches/ubuntu/raring/libnih/raring
You do not need the --session flag to run a "Session Init" (yes, this
is a little confusing but --session was added for testing a long time
ago and is still required for that). A "Session Init" only requires
"--user".

Julia: limit on the number of files open while using readdlm

I have some Julia code where I open a very large number of files using the readdlm function. My code looks like this:
for file in large_list_of_files
open(file) do filehandle
data = readdlm(filehandle)
end
#Do some data processing and store results
end
When I run this I get the error:
LoadError: SystemError: opening file <filename>: Too many open files
while loading In[28], in expression starting on line 28
in open at /Applications/Julia-0.4.0.app/Contents/Resources/juli/lib/julia/sys.dylib
in open at iostream.jl:102
in open at iostream.jl:112
in process_data at In[13]:11
[inlined code] from In[28]:31
in anonymous at no file:30
This doesn't make sense, since the do block should be closing the file every time I go around the loop, therefore the file should only be open in the do block. Also, if anyone knows a function in Julia that can count the number of files that are open, then that would be great :)
System info:
Mac OSX, Yosemite
Julia Version 0.4.0
Commit 0ff703b* (2015-10-08 06:20 UTC)
Platform Info:
System: Darwin (x86_64-apple-darwin13.4.0)
CPU: Intel(R) Core(TM) i7-3720QM CPU # 2.60GHz
WORD_SIZE: 64
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
LAPACK: libopenblas64_
LIBM: libopenlibm
LLVM: libLLVM-3.3
Also, I am running this code using Jupyter with a Julia 0.4.0 kernel, but I doubt that that would make any difference.
EDIT: I noticed this issue on Github, ViralBShah says that the problem is fixed but I don't think that it is.
https://github.com/JuliaLang/julia/issues/8891
EDIT EDIT: I have tried using the gc() function and that doesn't fix the problem either.
Seems to be solved:
Tested under
MacOS HighSierra 10.13.6
julia version 1.5.1
using DelimitedFiles
# 329571 files:
for file in split(String(read(a)),"\n")[1:end-1]
open(file) do fh
try readdlm(fh)
catch ff
end
end
end

Resources