opp_runall -q runnumbers returned nonzero exit status omnet++ - command-line

I try to run the simulation from command line with the following command,
$ opp_runall -j2 ./inetmanet-3.x-mactest2 -u Cmdenv -c General -r 1 -n ../..:../../../src:../../../tutorials --image-path=../../../images -l ../../../src/INET omnetpp.ini
I get a weird error, which does not make sense to me, any one can help as follows.
what(): ASSERT: Condition '(int)signalListenerCount.size() == lastSignalID+1' does not hold in function registerSignal, ccomponent.cc line 414 opp_runall: ./inetmanet-3.x-mactest2 [...] -q runnumbers returned nonzero exit status
I using omnetpp RC2 latest release, 1992-2017.
any help?

I stumbled upon the same problem. It is actually a bug/feature in newer versions of OMNeT++, where the signal handling was improved. I just discussed this problem with Attila Török on the mailing list.
This occurs if a signal is registered in an external library during static initialization. Three possible solutions:
Citing Attila:
Insert EXECUTE_ON_STARTUP(cComponent::clearSignalState()); into ccomponent.cc, right after the definition of cComponent::signalListenerCount, then rebuilding OMNeT++.
Move your signal registration out of the static initialization phase. This might or might not be possible in your scenario, but avoids modifications of OMNeT++ itself.
Downgrade OMNeT++ and wait until this is fixed upstream. At least 5.0 works.

Related

CalledProcessError: Command '\['git', 'submodule--helper', 'list'\]

all.
After I use devtool-modify to edit my recipe, when I bitbake my image, something wrong happend.
ExpansionError: Failure expanding variable do_compile\[file-checksums\], expression was ${#srctree_hash_files(d)} which triggered exception
CalledProcessError: Command '\['git', 'submodule--helper', 'list'\]' returned non-zero exit status 128.
The variable dependency chain for the failure is: do_compile\[file-checksums\]
11111111111111111111111111111111111
Git is no longer supports submodule--helper list , so fixed in https://git.yoctoproject.org/poky/commit/?id=0533edac277080e1bd130c14df0cbac61ba01a0c .
So you can either apply this commit or upgrade poky!

Avahi fails in buildroot running intltool-update

I'm using an older buildroot 2016.11 and want to add DNS-SD by selecting the avahi package. Resulting in this error:
Unescaped left brace in regex is illegal here in regex; marked by <-- HERE in m/^(.*)\${ <-- HERE ?([A-Z_]+)}?(.*)$/ at /home/user/nuvoton/nuc980/output/host/usr/bin/intltool-update line 1065.
checking for intltool >= 0.35.0... found
configure: error: Your intltool is too old. You need intltool 0.35.0 or later.
When searching I learned intltool should be enabed on the host, but I could not find how in menuconfig.
More searching told me it is related to some Perl update
I tried adding this patch http://lists.busybox.net/pipermail/buildroot/2017-June/194509.html but that also didn't help.
Can somebody steer me in the right direction how to solve this?
Using https://github.com/maximeh/buildroot/blob/master/package/intltool/0001-perl-5.26-compatibility.patch makes avahi build without problems.
In my case the build is getting too big, so I have to trim it down somehow...

openfoam ./makeParaview

i am currently building openfoam 1912 from source and have some trouble building paraview. I just build Qt and Cmake but as soon as i type ./makeParaview qt-5.9.9 5.6.3i get the following error:
./makeParaView: 64: local: -DWM_DP: bad variable name
./makeParaView: 64: ./makeParaView: -DOPENFOAM: bad variable name
A similar error occurs when i try to make VTK / Adios2. Any idea where i took the wrong turn?
Greetings
Gabbagandalf
The proper solution is related to shell quoting issues
- flag="$(stripCompilerFlags $flag)"
+ flag="$(stripCompilerFlags "$flag")"
but in the meantime you can simply change the shebang to #!/bin/bash - it is more forgiving.
As discussed and resolved in these GitLab ticket-1 and ticket-2:
The issue seems to be Ubuntu related.
Solution:
Prior to execute ./makeParaview, switch to bash:
Change the first line of makeParaView script to #!/bin/bash
sudo dpkg-reconfigure dash
./makeParaView

Issue with FFMPEG drawtext

ffmpeg -i /home/mysite/public_html/videos/thankyou/thankyou_1.mp4 -strict -2 -vf
"[in]drawtext=fontfile=/home/mysite/fonts/OswaldFont/Oswald-Bold.ttf: x=450:
y=150: fontsize=152: fontcolor=0xAE0216#1: draw='if(gt(n,40),lt(n,300))':
text='THANK YOU',drawtext=fontfile=/home/mysite/fonts/OswaldFont/Oswald-Bold.ttf:
x=450: y=320: fontsize=200: fontcolor=0xAE0216#1: draw='if(gt(n,50),lt(n,300))':
text='JAMISON'" /home/mysite/public_html/videos/thankyou_2.mp4
When running the above, I'm getting the following. It seems to run properly on other distributions. Not sure where to check next.
[Parsed_drawtext_0 # 0x2835480] Option 'draw' not found
[AVFilterGraph # 0x283f980] Error initializing filter 'drawtext' with args 'fontfile=/home/mysite/fonts/OswaldFont/Oswald-Bold.ttf: x=450: y=150: fontsize=152: fontcolor=0xAE0216#1: draw=if(gt(n,40),lt(n,300)): text=THANK YOU'
Error opening filters!
Additionally, this original command works fine in Ubuntu, but give the seen error when running in centOS.
According the the FFmpeg drawtext filter documentation:
draw
This option does not exist, please see the timeline system
This means you should use timeline editing instead.
To do that replace the draw='...' part of your command with:
enable=if(gt(n\,50)\,lt(n\,300))
You should also check:
FFmpeg versions on each machine. You might have an older version installed on Ubuntu, which supports the draw option, and a newer version on CentOS in which the option was removed.
if the font files exist

Tesseract problem with mftraining stage

I've successfully created a box file with tesseract
now after running the unicharset_extractor
having it creating the unicharset file that looks like:
...
n 3 NULL -1
s 3 NULL 23
t 3 NULL 43
...
I've continued with this command
mftraining -U unicharset -O testlang.unicharset testlang.tr
only to get the next error
Reading testlang.tr ...
testlang has no defined properties.
Error: Illegal short name for a feature!
I've never worked with Tesseract, but it seems there is an open issue in the bug database that looks a lot like your problem : http://code.google.com/p/tesseract-ocr/issues/detail?id=385
It seems that it is related to scientific notation not being correctly supported by some functions.
On the issue page a user suggests a solution, and another one proposes a patch. You could try applying the patch to see if it helps.