PyPLC

avatar par défaut
Remotie
Hi Sergi,
1 : i can't run ulimit -n 99999. i got this message:
bash: ulimit: open files: cannot modify limit: Operation not permitted

2 : i run gdb -c core -f /usr/bin/python
#> bt
but i got these message:

tango-cs@tango9-vm:~/Downloads/PyPLC-master/PyPLC$ gdb -c core -f /usr/bin/python
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 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:
<http://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/python…(no debugging symbols found)…done.
/home/tango-cs/Downloads/PyPLC-master/PyPLC/core: No such file or directory.
(gdb) bt
No stack.
(

3. PyPLC properties:
DynamicAttributes
T1=int(Reg(0000))
T2=int(Reg(0001))
T3=int(Reg(0002))

Modbus_name = mdb/test/1

Modbus DS properties
- Device Info —————————————-

Device: mdb/test/1
type_id: IDL:Tango/Device_5:1.0
iiop_version: 1.2
host: tango9-vm (10.0.2.15)
alternate addr.: 192.168.210.104
port: 45546
Server: Modbus/MDBT
Server PID: 4697
Exported: true
last_exported: 31st May 2017 at 16:21:33
last_unexported: ?

- Polling Status ————————————-


Thanks
rbourtembourg avatar
Reynald
Hello,

If I were you I would try:
ulimit -c unlimited
instead of the ulimit command suggested by Sergi…
I think the idea here is to configure Linux to create a core file when there is a crash of a process.

I recommend you to have a look at what is gdb (https://www.gnu.org/software/gdb/) and what does the ulimit command (https://ss64.com/bash/ulimit.html)
So if this ulimit command succeeds, the next time your PyPLC server will crash, it will create a core file.

gdb is a debugger which will allow us to locate which part of the code caused the crash… but you need to have a core file generated to be able to analyze it.
It might be that your Linux distribution will generate a core file having a name different than "core" so you will have to adapt the name of the core file passed after -c option of gdb. It might also be that it will create this core file in a special directory. You may refer to your Linux distribution documentation/community to know this location if this is the case.

Hoping this helps,
Reynald
Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.
avatar par défaut
Remotie
Hi
i add the core compressed file to this link
https://drive.google.com/open?id=0B6VsJcfDEMQreUhXbWJtS29nQkE

Regards
srubio avatar
sergi_rubio
Now that you have the core, run again GDB on it to obtain the backtrace (it has to be done in the very same machine)

run gdb -c core -f /usr/bin/python
#> bt
Keep on dancing,

http://www.tango-controls.org/resources/howto/how-fandango/
Edited 7 years ago
avatar par défaut
Remotie

Hi Sergi
this is the trace :
tango-cs@tango9-vm:~/Downloads/PyPLC-master/PyPLC$ gdb -c core -f /usr/bin/python
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 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:
<http://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/python…(no debugging symbols found)…done.

warning: core file may not match specified executable file.
[New LWP 9614]
[New LWP 7795]
[New LWP 7797]
[New LWP 7799]
[New LWP 7800]
[New LWP 7801]
[New LWP 9610]
[New LWP 7868]
[New LWP 7688]
[New LWP 7685]
[New LWP 7798]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `python PyPLC.py PLCT'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000000111 in ?? ()
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19-gdb.py", line 63, in <module>
    from libstdcxx.v6.printers import register_libstdcxx_printers
ImportError: No module named 'libstdcxx'
(gdb) bt
#0  0x0000000000000111 in ?? ()
#1  0x00007fc4777a4861 in ~auto_ptr (this=0x1704e60, __in_chrg=<optimized out>)
    at /usr/include/c++/4.8/backward/auto_ptr.h:170
#2  boost::python::objects::pointer_holder_back_reference<std::auto_ptr<CppDeviceClassWrap>, CppDeviceClass>::~pointer_holder_back_reference (this=0x1704e50, 
    __in_chrg=<optimized out>)
    at /usr/include/boost/python/object/pointer_holder.hpp:88
#3  0x00007fc476a20907 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libboost_python-py27.so.1.54.0
#4  0x00000000004f7148 in ?? ()
#5  0x00000000004ad7ec in _PyObject_GenericSetAttrWithDict ()
#6  0x00000000004d6436 in ?? ()
#7  0x00000000004adb99 in PyObject_SetAttr ()
#8  0x000000000049a356 in PyEval_EvalFrameEx ()
#9  0x00000000004a1c9a in ?? ()
#10 0x00000000004dfe94 in ?? ()
#11 0x00000000004dc9cb in PyEval_CallObjectWithKeywords ()
#12 0x00000000005a65b1 in PyEval_CallMethod ()
#13 0x00007fc4777a3032 in call_method<void, Tango::DevVarStringArray const*> (
    name=0x7fc47783e17f "device_factory", a0=<synthetic pointer>, 
    self=0x7fc4707047e0) at /usr/include/boost/python/call_method.hpp:66
#14 CppDeviceClassWrap::device_factory (this=<optimized out>, 
    dev_list=0x7fc4667fbbf0)
—Type <return> to continue, or q <return> to quit—
    at /tmp/PyTango/src/boost/cpp/server/device_class.cpp:222
#15 0x00007fc476e102da in Tango::DServer::init_device() ()
   from /usr/lib/x86_64-linux-gnu/libtango.so.8
#16 0x00007fc476e0e1d3 in Tango::ServRestartThread::run(void*) ()
   from /usr/lib/x86_64-linux-gnu/libtango.so.8
#17 0x00007fc474ab0673 in omni_thread_wrapper ()
   from /usr/lib/libomnithread.so.3
#18 0x00007fc479140182 in start_thread (arg=0x7fc4667fc700)
    at pthread_create.c:312
#19 0x00007fc478e6d47d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Regards
srubio avatar
sergi_rubio
Hi,

Here we have something to search for. I'll have a look and come back with an answer next week.

Sergi
Keep on dancing,

http://www.tango-controls.org/resources/howto/how-fandango/
srubio avatar
sergi_rubio
Hi,

I'm very sorry but I couldn't replicate the error. My guess is that something stored in the Tango DB is corrupting somehow the loading of properties.

Could you create a new PyPLC device server with all properties empty except Modbus_name and see if the error also occurs?

Sergi
Keep on dancing,

http://www.tango-controls.org/resources/howto/how-fandango/
srubio avatar
sergi_rubio
In case of need, you may have a look to the new C++ equivalent of PyPLC.

I think is property-compatible so you may use it as an alternative if your error persists:

https://www.ict.inaf.it/indico/event/514/session/8/contribution/47/material/slides/2.pptx
Keep on dancing,

http://www.tango-controls.org/resources/howto/how-fandango/
 
Register or login to create to post a reply.