[dune-pdelab] Unknown exception
conf86 at web.de
conf86 at web.de
Thu Sep 3 23:33:26 CEST 2015
> I don't think that is done in many places in Dune, so you could try and grep
> for "exceptions *\(" or similar, maybe one of the occurrences will tell you
> something.
>
> Failing that, you can try running your program through strace so see what the
> last I/O-operation was.
>
> Failing that, you can try recompiling with debug symbols, running the program
> in gdb, and doing ye olde "catch throw" thingy to see the backtrace.
>
> When debugging, be aware of your locale. Some libraries can set the locale
> from the environment behind your back. If that locale is german, reading
> floating point numbers may stop working because the expected format is
> suddenly "3,1415" instead of "3.1415". There are probably places in Dune that
> are not guarding against such locale issues.
Thank you for your answer!
I didn't find anything in dune about exceptions that seemed easily comprehensible and usable to me, so I tried strace first.
"strace -p 2345" gave me (where the error occurs):
write(1, "TIME STEP [Alexander (order 2)] "..., 106) = 106
write(1, "STAGE 1 time (to): 2.6229e+1."..., 33) = 33
clock_gettime(CLOCK_REALTIME, {1441296518, 490235862}) = 0
clock_gettime(CLOCK_REALTIME, {1441296518, 490296341}) = 0
write(1, "=== matrix setup skipped (matrix"..., 52) = 52
clock_gettime(CLOCK_REALTIME, {1441296518, 576937068}) = 0
write(1, "=== matrix assembly (max) 0.0866"..., 36) = 36
clock_gettime(CLOCK_REALTIME, {1441296518, 577050763}) = 0
clock_gettime(CLOCK_REALTIME, {1441296518, 587970516}) = 0
write(1, "=== residual assembly (max) 0.01"..., 38) = 38
clock_gettime(CLOCK_REALTIME, {1441296518, 588079392}) = 0
clock_gettime(CLOCK_REALTIME, {1441296518, 588166689}) = 0
clock_gettime(CLOCK_REALTIME, {1441296518, 591548279}) = 0
clock_gettime(CLOCK_REALTIME, {1441296518, 591600028}) = 0
write(1, "=== solving (reduction: 1e-10) 0"..., 42) = 42
write(1, "STAGE 2 time (to): 2.6300e+1."..., 33) = 33
clock_gettime(CLOCK_REALTIME, {1441296518, 603404340}) = 0
clock_gettime(CLOCK_REALTIME, {1441296518, 603446940}) = 0
write(1, "=== matrix setup skipped (matrix"..., 52) = 52
clock_gettime(CLOCK_REALTIME, {1441296518, 659795129}) = 0
write(1, "=== matrix assembly (max) 0.0563"..., 36) = 36
clock_gettime(CLOCK_REALTIME, {1441296518, 659931172}) = 0
clock_gettime(CLOCK_REALTIME, {1441296518, 668703150}) = 0
write(1, "=== residual assembly (max) 0.00"..., 39) = 39
clock_gettime(CLOCK_REALTIME, {1441296518, 668808186}) = 0
clock_gettime(CLOCK_REALTIME, {1441296518, 668883331}) = 0
clock_gettime(CLOCK_REALTIME, {1441296518, 671704057}) = 0
clock_gettime(CLOCK_REALTIME, {1441296518, 671747077}) = 0
write(1, "=== solving (reduction: 1e-10) 0"..., 42) = 42
write(1, "::: timesteps 263 (263)\n", 32) = 32
write(1, "::: nl iterations 1575 (1575)"..., 33) = 33
write(1, "::: lin iterations 1575 (1575)"..., 33) = 33
write(1, "::: assemble time 4.0737e+01 "..., 45) = 45
write(1, "::: lin solve time 1.7419e+00 "..., 45) = 45
open("problem_Q2-00263.vtu", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT
(No such file or directory)
munmap(0x7f51e9f66000, 315392) = 0
brk(0) = 0x15fd000
brk(0) = 0x15fd000
brk(0x1491000) = 0x1491000
brk(0) = 0x1491000
munmap(0x7f51c8e68000, 524292096) = 0
write(2, "Unknown exception thrown!", 25) = 25
write(2, "\n", 1) = 1
write(2, "terminate called after throwing "..., 48) = 48
write(2, "std::ios_base::failure", 22) = 22
write(2, "'\n", 2) = 2
write(2, " what(): ", 11) = 11
write(2, "basic_ios::clear", 16) = 16
write(2, "\n", 1) = 1
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
gettid() = 2345
tgkill(2345, 2345, SIGABRT) = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=2345,
si_uid=630} ---
+++ killed by SIGABRT (core dumped) +++
It seems the program wants to open the file "problem_Q2-00263.vtu" which does not exist.
However, there were no .vtu files in the directory beforehand and shouldn't the program actually create the files?
I then jokingly copied "problem_Q2-00262.vtu" to "problem_Q2-00263.vtu" and run the program while keeping the .vtu files to see what would happen and then it actually worked.
After removing all the files again and running the program, it still worked fine.
I have no idea what happened here, because I haven't changed anything in the code or elsewhere, but now it seems to work again.
I don't know, does it still makes sense to try debugging here? The problem is not really resolved, but it just vanished.
Best regards
More information about the dune-pdelab
mailing list