I have a script (vhs - video handler script, using ffmpeg) to encode videos.
It also encodes a dvd, but until now just non-copy-protected ones, so i've tried to add/implement a vobcopy wrapper to be used by my script.
At first it looked quite fine, but when changing from the first VOB to the 2nd VOB, it copies a few megabytes, and then fails, with said error message.
Here's the output:
# | vhs (1.2) Video Handler Script 2014-12-27 02:07:34 | #
# | Please select which entry is the DVD: | #
1) Avatar
2) Inside_Man
#? 1
# | Encoding Avatar | #
# | Mounted DVD to /run/media/sea/Avatar [ ] | #
# | Please select a method: | #
# | 1) Encode directly from DVD 2) Copy largest files to local | #
# | > 2
# | /home/sea/.cache/Avatar already exists, reuse it? (y/n) n | #
# | Copy vob files to "/home/sea/.cache/Avatar", this may take a while... | #
# | Copied: AVATAR1-1.vob [ ] | #
# | pid:20608 Copying: AVATAR1-2.vob (124M) [ / ] | #
/home/sea/.local/bin/vhs.sh: line 658: 20608 Floating point exception(core dumped) vobcopy -o "$1" 2> "$vTMP"
# | pid:20608 Copying: AVATAR1-2.vob (130M) [ - ] | #
~/data/tmp $ cat -n ~/.local/bin/vhs.sh | grep -A44 \ 635
635 doVobCopy() { # "OUTDIR"
636 # Uses vobcopy to copy the vobs to OUTDIR
637 #
638 [[ -z "$1" ]] && exit 1
639 declare files
640 unset files
641 count=0
642
643 if $showFFMPEG
644 then vobcopy -o "$1"
645 else # Do the job in the background
646 vTMP="${TMP}.vobcopy" # File to 'get' all the output
647 [[ -f "$vTMP" ]] && rm -f "$vTMP"
648 touch "$vTMP"
649
650 vobcopy -o "$1" 2>"$vTMP" &
651 PID=$!
652 sleep 0.3
653
654 while ps | grep -q $PID
655 do # Retrieve the filename and print its filesize to user
656 FILE=$(tail -n 2 "$vTMP"|grep Outputting|awk '{print $4}')
657 if [[ ! -z "$FILE" ]]
658 then FILE=$(basename "$FILE")
659 msg="Copying: $FILE"
660 msg_P="pid:$PID"
661
662 if echo "${files[@]}" | grep -q "$FILE"
663 then tui-printf "$msg_P" \
664 "$msg ($(ls -lh $1/$FILE*|awk '{print $5}'))" \
665 "[ $(tui-indi) ]"
666 else files[${#files[@]}]="$FILE"
667 [[ $count -gt 0 ]] && \
668 tui-status 0 "Copied: ${files[ $[ $count - 1 ] ]}"
669 count=$(($count + 1))
670 tui-printf "$msg_P" \
671 "$msg" \
672 "[ $(tui-indi) ]"
673 fi
674 fi
675 sleep 0.7
676 done
677 fi
678 rm -f "$vTMP"
679 }
:) ~/data/tmp $
I've never beofre had a floating point issue., so i'd rather think its a vobcopy issue than mine..
Anyhow, i do not know how to identify a floating point issue, with the above code, there is no math done (but adding 1 to 'c' which was set to 0). but subtracting 1 from ${#files[@]} , but this just happens when its 1 or higher.
Any advice or ideas?
Thank you in advance and happy holidays.
we can see that vobcopy dropped a core file due to a floating point exception. Where that core file is placed varies from system to system. Start by looking at the man page for core and gdb or adb or sdb on your system to see if they give you an indication of where the core file is located.
ongoto:
No, the core didn't come from test. The diagnostic output repeated above clearly states that vobcopy received a floating point exception and a core file was produced.
According to man core this Fedora release saves the core dumps either as 'core' or 'core.pid'.
So i used locate, but it didnt find a 'core.pid' and looking for just core, brought just one 'reasonable' result (same as when i look - for 'fun' - for coredump:
cat /etc/systemd/coredump.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# See coredump.conf(5) for details
[Coredump]
#Storage=external
#Compress=yes
#ProcessSizeMax=2G
#ExternalSizeMax=2G
#JournalSizeMax=767M
#MaxUse=
#KeepFree=
cat /usr/lib/sysctl.d/50-coredump.conf
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
# See sysctl.d(5) for the description of the files in this directory,
# and systemd-coredump(8) and core(5) for the explanation of the
# setting below.
kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e
/var/lib/systemd $ ll
total 24K
drwxr-xr-x. 2 root root 4.0K Dec 14 00:20 backlight
drwxr-xr-x. 2 root root 4.0K Dec 14 15:20 catalog
drwxr-xr-x. 2 root root 4.0K Nov 10 16:18 coredump
drwxr-xr-x. 2 root root 4.0K Dec 14 15:35 rfkill
drwxr-xr-x. 2 root root 4.0K Dec 14 15:04 timers
-rw-------. 1 root root 512 Dec 26 22:47 random-seed
+ /var/lib/systemd $ ll coredump/
total 0
So it seems it didnt procude a coredump
As there are no files within the 'coredump' directory.
coredumpctl list
No coredumps found.
This seems to verify this...
I'm going to try this again as root, and hope it creates a dump file then..
Note that it wouldn't literally be core.pid , it would be core.ProcessIDOfProgramThatDroppedCore (which in this case would be core.20608 ).
It looks like /var/lib/systemd/coredump is used when your system crashes (not when user processes running on your system crash). On most systems I've used, a core file would be placed in the directory that:
was the current working directory of the process when it died,
was the current working directory of the process when it started,
was the home directory of the user who started the process, or
was a subdirectory of the home directory of the user who started the process.
The diagnostic you received from bash :
/home/sea/.local/bin/vhs.sh: line 658: 20608 Floating point exception(core dumped) vobcopy -o "$1" 2> "$vTMP"
indicates that bash was told that a core file was produced. But, obviously, configuration parameters can disable core file production.
If locate core and core.20608 don't find anything, we have to assume that your system didn't drop a core or some cron job removed it before you looked for it.
Sadly, the change of the literal 'pid' to its PID didnt bring up any locate result.
That was right now after it failed again, on yet another dvd... guess i got to live with the regular console output of vobcopy...
