[Dachs-support] DaCHS dachs command returns illegal instruction
Nima Traore
nima.traore at universite-paris-saclay.fr
Tue Nov 7 12:37:43 CET 2023
Hi Markus,
Thank you very much for this information :) Here is below the output of the where command in the gdb:
~$ gdb `which python3` core
GNU gdb (Debian 13.1-3) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/python3...
(No debugging symbols found in /usr/bin/python3)
[New LWP 116465]
[New LWP 116466]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/python3 /usr/bin/dachs --version'.
Program terminated with signal SIGILL, Illegal instruction.
#0 0x00007fb95b366820 in dgemm_otcopy_OPTERON_SSE3 () from /lib/x86_64-linux-gnu/libopenblas.so.0
[Current thread is 1 (Thread 0x7fb95eabd040 (LWP 116465))]
(gdb) where
#0 0x00007fb95b366820 in dgemm_otcopy_OPTERON_SSE3 () from /lib/x86_64-linux-gnu/libopenblas.so.0
#1 0x0000000000000003 in ?? ()
#2 0x0000000000000003 in ?? ()
#3 0x0000000000000003 in ?? ()
#4 0x00007fb946c87040 in ?? ()
#5 0x0000000000000003 in ?? ()
#6 0x00007fb95cb8bdb0 in ?? () from /lib/x86_64-linux-gnu/libopenblas.so.0
#7 0x00007fb95aad0dc9 in dgemm_nn () from /lib/x86_64-linux-gnu/libopenblas.so.0
#8 0x00007fb95cbd1033 in cblas_dgemm () from /lib/x86_64-linux-gnu/libblas.so.3
#9 0x00007fb95cf5cd6d in ?? () from /usr/lib/python3/dist-packages/numpy/core/_multiarray_umath.cpython-311-x86_64-linux-gnu.so
#10 0x00007fb95cf60385 in ?? () from /usr/lib/python3/dist-packages/numpy/core/_multiarray_umath.cpython-311-x86_64-linux-gnu.so
#11 0x00007fb95cf6bce7 in ?? () from /usr/lib/python3/dist-packages/numpy/core/_multiarray_umath.cpython-311-x86_64-linux-gnu.so
#12 0x000000000054618f in ?? ()
#13 0x0000000000545b88 in PyObject_CallFunctionObjArgs ()
#14 0x00000000005519cd in ?? ()
#15 0x0000000000641d79 in ?? ()
#16 0x000000000052cbb7 in _PyEval_EvalFrameDefault ()
#17 0x000000000052360b in PyEval_EvalCode ()
#18 0x000000000058ec4e in ?? ()
#19 0x000000000053acf7 in ?? ()
#20 0x00000000005343b0 in _PyEval_EvalFrameDefault ()
#21 0x000000000055c931 in _PyFunction_Vectorcall ()
#22 0x000000000054618f in ?? ()
#23 0x000000000058351b in PyObject_CallMethodObjArgs ()
#24 0x0000000000451a11 in ?? ()
#25 0x000000000059e9c3 in ?? ()
#26 0x000000000053acf7 in ?? ()
#27 0x00000000005343b0 in _PyEval_EvalFrameDefault ()
#28 0x000000000055c931 in _PyFunction_Vectorcall ()
#29 0x000000000054618f in ?? ()
#30 0x000000000058351b in PyObject_CallMethodObjArgs ()
#31 0x000000000045277e in ?? ()
#32 0x0000000000530a23 in _PyEval_EvalFrameDefault ()
#33 0x000000000052360b in PyEval_EvalCode ()
#34 0x000000000058ec4e in ?? ()
#35 0x000000000053acf7 in ?? ()
#36 0x00000000005343b0 in _PyEval_EvalFrameDefault ()
#37 0x000000000055c931 in _PyFunction_Vectorcall ()
#38 0x000000000054618f in ?? ()
#39 0x000000000058351b in PyObject_CallMethodObjArgs ()
#40 0x0000000000451a11 in ?? ()
#41 0x0000000000530a23 in _PyEval_EvalFrameDefault ()
--Type <RET> for more, q to quit, c to continue without paging--RET
#42 0x000000000052360b in PyEval_EvalCode ()
#43 0x000000000058ec4e in ?? ()
#44 0x000000000053acf7 in ?? ()
#45 0x00000000005343b0 in _PyEval_EvalFrameDefault ()
#46 0x000000000055c931 in _PyFunction_Vectorcall ()
#47 0x000000000054618f in ?? ()
#48 0x000000000058351b in PyObject_CallMethodObjArgs ()
#49 0x0000000000451a11 in ?? ()
#50 0x0000000000530a23 in _PyEval_EvalFrameDefault ()
#51 0x000000000052360b in PyEval_EvalCode ()
#52 0x000000000058ec4e in ?? ()
#53 0x000000000053acf7 in ?? ()
#54 0x00000000005343b0 in _PyEval_EvalFrameDefault ()
#55 0x000000000055c931 in _PyFunction_Vectorcall ()
#56 0x000000000054618f in ?? ()
#57 0x000000000058351b in PyObject_CallMethodObjArgs ()
#58 0x0000000000451a11 in ?? ()
#59 0x0000000000530a23 in _PyEval_EvalFrameDefault ()
#60 0x000000000052360b in PyEval_EvalCode ()
#61 0x000000000058ec4e in ?? ()
#62 0x000000000053acf7 in ?? ()
#63 0x00000000005343b0 in _PyEval_EvalFrameDefault ()
#64 0x000000000055c931 in _PyFunction_Vectorcall ()
#65 0x000000000054618f in ?? ()
#66 0x000000000058351b in PyObject_CallMethodObjArgs ()
#67 0x0000000000451a11 in ?? ()
#68 0x000000000059e9c3 in ?? ()
#69 0x000000000053acf7 in ?? ()
#70 0x00000000005343b0 in _PyEval_EvalFrameDefault ()
#71 0x000000000055c931 in _PyFunction_Vectorcall ()
#72 0x000000000054618f in ?? ()
#73 0x000000000058351b in PyObject_CallMethodObjArgs ()
#74 0x000000000045277e in ?? ()
#75 0x0000000000530a23 in _PyEval_EvalFrameDefault ()
#76 0x000000000052360b in PyEval_EvalCode ()
#77 0x000000000058ec4e in ?? ()
#78 0x000000000053acf7 in ?? ()
#79 0x00000000005343b0 in _PyEval_EvalFrameDefault ()
#80 0x000000000055c931 in _PyFunction_Vectorcall ()
#81 0x000000000054618f in ?? ()
#82 0x000000000058351b in PyObject_CallMethodObjArgs ()
#83 0x0000000000451a11 in ?? ()
--Type <RET> for more, q to quit, c to continue without paging--RET
#84 0x0000000000530a23 in _PyEval_EvalFrameDefault ()
#85 0x000000000052360b in PyEval_EvalCode ()
#86 0x000000000058ec4e in ?? ()
#87 0x000000000053acf7 in ?? ()
#88 0x00000000005343b0 in _PyEval_EvalFrameDefault ()
#89 0x000000000055c931 in _PyFunction_Vectorcall ()
#90 0x000000000054618f in ?? ()
#91 0x000000000058351b in PyObject_CallMethodObjArgs ()
#92 0x0000000000451a11 in ?? ()
#93 0x000000000059e9c3 in ?? ()
#94 0x000000000053acf7 in ?? ()
#95 0x00000000005343b0 in _PyEval_EvalFrameDefault ()
#96 0x000000000055c931 in _PyFunction_Vectorcall ()
#97 0x000000000054618f in ?? ()
#98 0x000000000058351b in PyObject_CallMethodObjArgs ()
#99 0x000000000045277e in ?? ()
#100 0x0000000000530a23 in _PyEval_EvalFrameDefault ()
#101 0x000000000055c931 in _PyFunction_Vectorcall ()
#102 0x000000000052f8a2 in _PyEval_EvalFrameDefault ()
#103 0x000000000052360b in PyEval_EvalCode ()
#104 0x0000000000647497 in ?? ()
#105 0x0000000000644d4f in ?? ()
#106 0x0000000000651010 in ?? ()
#107 0x0000000000650d5b in _PyRun_SimpleFileObject ()
#108 0x0000000000650b84 in _PyRun_AnyFileObject ()
#109 0x000000000064f90f in Py_RunMain ()
#110 0x00000000006275c7 in Py_BytesMain ()
#111 0x00007fb95eae51ca in __libc_start_call_main (main=main at entry=0x627530, argc=argc at entry=3, argv=argv at entry=0x7fff2f60b8f8)
at ../sysdeps/nptl/libc_start_call_main.h:58
#112 0x00007fb95eae5285 in __libc_start_main_impl (main=0x627530, argc=3, argv=0x7fff2f60b8f8, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fff2f60b8e8) at ../csu/libc-start.c:360
#113 0x0000000000627461 in _start ()
(gdb)
I haven't done any updates with aptitude yet. I'm waiting for your feedback to see things more clearly.
Best regards,
Nima
De: dachs-support-request at g-vo.org
À: "dachs-support" <dachs-support at g-vo.org>
Envoyé: Samedi 4 Novembre 2023 12:00:01
Objet: Dachs-support Digest, Vol 32, Issue 2
Send Dachs-support mailing list submissions to
dachs-support at g-vo.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.g-vo.org/mailman/listinfo/dachs-support
or, via email, send a message with subject or body 'help' to
dachs-support-request at g-vo.org
You can reach the person managing the list at
dachs-support-owner at g-vo.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dachs-support digest..."
Today's Topics:
1. problem with getproduct (Chloé Azria)
2. Re: DaCHS dachs command returns illegal instruction
(Markus Demleitner)
3. Re: problem with getproduct (Markus Demleitner)
----------------------------------------------------------------------
Message: 1
Date: Fri, 3 Nov 2023 17:15:11 +0100
From: Chloé Azria <chloe.azria at obspm.fr>
To: dachs-support at g-vo.org
Subject: [Dachs-support] problem with getproduct
Message-ID: <c4950e15-74e0-4d66-bf53-e65fc72faf69 at obspm.fr>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi Markus,
I have a problem with the getproduct method.
The service parsec buildt by Emil Wilawer uses the
|makeProductLink(@prodtblAccref) |and we don't manage to make it work,
the link returned on the acces_url column leads to the error "No dataset
with accref parsec/data/asteroid/dataset_2/0943bc9f43502d81.fts" known here.
the url is like
http://<<servername>>:<<port>>/getproduct/parsec/data/asteroid/dataset_2/0943bc9f43502d81.fts
I have tested it on several servers and sometimes it works and sometimes
it don't.
Is it a server configuration problem or something else ?
Thank you very much,
Chloé Azria
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.g-vo.org/pipermail/dachs-support/attachments/20231103/77a46e76/attachment-0001.htm>
------------------------------
Message: 2
Date: Fri, 3 Nov 2023 09:06:26 -0400
From: Markus Demleitner <msdemlei at ari.uni-heidelberg.de>
To: dachs-support at g-vo.org
Subject: Re: [Dachs-support] DaCHS dachs command returns illegal
instruction
Message-ID: <20231103130626.ynhzs4qy3dtt6l3h at victor>
Content-Type: text/plain; charset=utf-8
Nima,
On Thu, Nov 02, 2023 at 04:22:05PM +0100, Nima Traore wrote:
> We upgraded our DaCHS server from version 2.6 to version 2.8.2 a
> few weeks ago. Since yesterday, the dachs command (examples: 'dachs
> --version', 'dachs serve' etc.) systematically returns 'illegal
> instruction' and we are no longer able to restart the service. What
> do we have to do ?
"Illegal Instruction" is almost certainly the result of *something*
causing a SIGILL trap (cf. man 7 signal), that is, a binary gave the
CPU some instruction that it doesn't understnad.
It's almost impossible that DaCHS, being Python and containing no
machine code, does this by itself. The most plausible reason is that
there's a bug in some dependency that, I'd guess, causes stuff to be
executed that isn't machine code at all (but then you could also have
a library compiled for a different architecture or whatever).
How do you fix it? Well, I suppose the most straightforward thing is
to install aptitude, run sudo aptitude, navigate to the
python3-gavodachs package, open its dependencies and re-install one
after the other (type "e" in aptitude).
If you want to go a little less blindly, a somewhat more principled
approach is to apt install gdb, and then
$ ulimit -c unlimited # enable core dumps
$ dachs --version
$ gdb `which python3` core
In the gdb, type "where" to see where the thing crashed.
(provided you don't have something that puts the core dumps somewhere
else, in which case you'd have to replace the "core" here with the
path to the core dump ). See also
<http://docs.g-vo.org/DaCHS/booster.html#debugging>.
If you send me the output of the where command in the gdb, I may be
able to do somewhere more educated guesses as to the nature of the
problem.
-- Markus (currently in UTC-4)
------------------------------
Message: 3
Date: Fri, 3 Nov 2023 14:39:34 -0500
From: Markus Demleitner <msdemlei at ari.uni-heidelberg.de>
To: dachs-support at g-vo.org
Subject: Re: [Dachs-support] problem with getproduct
Message-ID: <20231103193934.4zeojp6drhfvxu2z at victor>
Content-Type: text/plain; charset=utf-8
Dear Chloé,
On Fri, Nov 03, 2023 at 05:15:11PM +0100, Chloé Azria wrote:
> I have a problem with the getproduct method.
>
> The service parsec buildt by Emil Wilawer uses the
> |makeProductLink(@prodtblAccref) |and we don't manage to make it work, the
> link returned on the acces_url column leads to the error "No dataset with
> accref parsec/data/asteroid/dataset_2/0943bc9f43502d81.fts" known here.
>
> the url is like http://<<servername>>:<<port>>/getproduct/parsec/data/asteroid/dataset_2/0943bc9f43502d81.fts
>
> I have tested it on several servers and sometimes it works and sometimes it
> don't.
>
> Is it a server configuration problem or something else ?
Hard to tell without knowing more. So... the basic operation of
getproduct is almost trivial: It looks up whatever is after the
"getproduct" in the URL (in your case
"parsec/data/asteroid/dataset_2/0943bc9f43502d81.fts") in the accref
column of the product table
<http://docs.g-vo.org/DaCHS/ref.html#dc-products> and hands out the
file pointed to in the accessPath column (these values in general
come from the //products#define rowfilter in the importing grammar).
If getproducts returns a 404, either the accref is missing (does the
epn-tap table mix in //products#table, perhaps indirectly?), or the
accessPath is wrong (have you perhaps moved the data around? Are
there case issues in case there's a case-insensitive file system in
the game?).
Now, as usual with computers, there's always the possibility of crazy
stuff completely different from this, but making sure the basics are
in place is a good idea.
If you figure it out, please let us know what went wrong -- if not,
by all means ask back.
Thanks,
Markus
------------------------------
Subject: Digest Footer
Dachs-support mailing list
Dachs-support at g-vo.org
https://lists.g-vo.org/mailman/listinfo/dachs-support
------------------------------
End of Dachs-support Digest, Vol 32, Issue 2
********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.g-vo.org/pipermail/dachs-support/attachments/20231107/a8d6cf1b/attachment-0001.htm>
More information about the Dachs-support
mailing list