Re: right list for SIGABRT python binary question ?

2017-11-04 Thread Karsten Hilbert 
On Fri, Nov 03, 2017 at 07:31:56AM +0100, dieter wrote:

> > I have posted backtraces taken from the address being
> > watched. Does that help any at all ?
> 
> Only in the case that the error is "local", i.e. detected
> (quite) immediately.
> 
> You might be in this case as you have observed that the address
> is stable after library preload. Thus, it might not be a heap
> address but one associated with one of the libraries. Such
> a memory block should never be "freed". The backtrace would allow
> you to determine the library affected. Obtain its source. Recompile
> with symbols and try to find out where this memory block comes from.

Dieter, thanks for taking the time to explain the general
procedure. However, recompiling a library and trying to find
out where given block of memory comes from is way beyond
skills. I fear I have reached the end of what I can do.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-11-03 Thread dieter 
Karsten Hilbert  writes:
> ...
> I have posted backtraces taken from the address being
> watched. Does that help any at all ?

Only in the case that the error is "local", i.e. detected
(quite) immediately.

You might be in this case as you have observed that the address
is stable after library preload. Thus, it might not be a heap
address but one associated with one of the libraries. Such
a memory block should never be "freed". The backtrace would allow
you to determine the library affected. Obtain its source. Recompile
with symbols and try to find out where this memory block comes from.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-11-02 Thread Karsten Hilbert 
On Wed, Nov 01, 2017 at 04:28:02PM +, Grant Edwards wrote:

> >>I understand. Thank you for the explanation. This may seem
> >>like a dumb question: the actual address that gets corrupted
> >>varies from run to run (it may be the same "place" in the
> >
> > Since the process virtual memory space should be the same on each run
> 
> Not with modern OS kernels:
> 
> https://en.wikipedia.org/wiki/Address_space_layout_randomization

I feared as much. However, I discovered that during
subsequent runs the address seems stable due to shared
libraries being preloaded: On the first run the affected code
is loaded at some randomized address and the corruption is
hit at a certain address giving me the value to watch on
during subsequent runs, as long as the affected code is not
evicted from being preloaded the address is stable.

I have posted backtraces taken from the address being
watched. Does that help any at all ?

Thanks,
Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-11-02 Thread dieter 
Karsten Hilbert  writes:
>> >> It points to a memory corruption.
>> 
>> The i386/x64 architecture supports memory access breakpoints
>> and GDB, too, has support for this. You know the address which
>> gets corrupted. Thus, the following apporach could have a chance
>> to succeed:
>> 
>>Put a "memory write" breakpoint on the address which gets corrupted.
>>this should stop the program each time this address is written;
>>Check then the backtrace. As the address forms part of the
>>address block prologue, it should only be accessed from
>>Python's "malloc" (and "free") implementation. Any other access
>>indicates bad behaviour.
>
> I understand. Thank you for the explanation. This may seem
> like a dumb question: the actual address that gets corrupted
> varies from run to run (it may be the same "place" in the
> code but that place gets put at a different address each
> run).

That's sad.

It is a long time ago (more than 10 years)
that I had to analyse such a kind of memory corruption. Fortunately,
in my case, the address was stable accross runs.
Likely, ASLR was not yet used by that time on a standard Linux platform.

Maybe, you find a way to disable ASLR.

If ASLR is the cause of the randomness, it might also be possible to
compute the new address. More on this later.


In another message, you reported how you tried to obtain an invariant
for the affected address by using "info symbol". I have not much
hope that this will succeed:
It is most likely, that the corrupted memory block is part of the
heap (in may also be a stack block, wrongly freed; this would be
a local error - and easily detectable from the traceback).
If you use "info symbol" on a heap address, you get not very
reliable information - especially, if ASLR is in effect (which
randomizes the various process segments and the heap blocks
independently from one another).


Back to an approach how to maybe compute the corrupted address
for a new run. The approach assumes a heap address and
uses that "mallog" (and friends) request large (which means hopefully few)
memory blocks from the OS which are then split into smaller blocks internally.
You can then catalog the large memory block requests and determine
the index of the block and the corrupted offset. In a following run,
you determine the new base address of this block and apply the
same offset to find the corrupted address.

Of cause, this assumes that your application is totally deterministic
(apart from maybe ASLR).

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-11-01 Thread Grant Edwards 
On 2017-11-01, Dennis Lee Bieber  wrote:
> On Wed, 1 Nov 2017 10:27:54 +0100, Karsten Hilbert
> declaimed the following:
>
>
>>
>>I understand. Thank you for the explanation. This may seem
>>like a dumb question: the actual address that gets corrupted
>>varies from run to run (it may be the same "place" in the
>
>   Since the process virtual memory space should be the same on each run

Not with modern OS kernels:

https://en.wikipedia.org/wiki/Address_space_layout_randomization

-- 
Grant Edwards   grant.b.edwardsYow! ... My pants just went
  at   on a wild rampage through a
  gmail.comLong Island Bowling Alley!!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-11-01 Thread Karsten Hilbert 
On Wed, Nov 01, 2017 at 11:58:53AM -0400, Dennis Lee Bieber wrote:

> >I understand. Thank you for the explanation. This may seem
> >like a dumb question: the actual address that gets corrupted
> >varies from run to run (it may be the same "place" in the
> 
>   Since the process virtual memory space should be the same on each run
> -- even heap allocations should be deterministic, UNLESS the program is
> doing things with external non-deterministic data (the time of day, random
> numbers not initialized with a repeatable seed, dynamic web pages, multiple
> threads that are non-deterministic due to I/O delays, etc.),

Mine doesn't to my knowledge hence I can expect "fixed"
addresses -- which is confirmed by what I found during
consecutive runs. Thanks for the affirmative explanation.

> the only other source for varying addresses would be
> OS-level shared libraries that are getting mapped at
> different locations due to changes in the order of other
> programs running.

IOW I should take care I haven't run any relevant amount of
Python code before debugging this problem, it seems ?

> The physical memory may vary due to paging fragmentation,
> but should still be the same virtual addresses.

I see.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-11-01 Thread Karsten Hilbert 
On Wed, Nov 01, 2017 at 12:40:56PM +0100, Karsten Hilbert wrote:

> Interestingly, on subsequent runs, it seems to hit the same
> address, 0x6aab7c, belonging to the same symbol, _Py_ZeroStruct.
> 
> This is what happens:
> 
>   (gdb) watch *0x6aab7c
>   Hardware watchpoint 1: *0x6aab7c
>   (gdb) run
>   Starting program: /usr/bin/python2.7-dbg ./bootstrap_gm_db_system.py 
> --log-file=./bootstrap-latest.log --conf-file=bootstrap-latest.conf --
>   [Thread debugging using libthread_db enabled]
>   Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
> 
>   Hardware watchpoint 1: *0x6aab7c
> 
>   Old value = 0
>   New value = -1208182272
>   _Py_AddToAllObjects (op=False, force=0) at ../Objects/object.c:70
>   70  ../Objects/object.c: Datei oder Verzeichnis nicht gefunden.
>   (gdb)

I forgot the backtrace from this point:

(gdb) bt
#0  _Py_AddToAllObjects (op=False, force=0) at ../Objects/object.c:70
#1  0x0051e052 in _PyBuiltin_Init () at ../Python/bltinmodule.c:2708
#2  0x0055bebf in Py_InitializeEx (install_sigs=1) at 
../Python/pythonrun.c:233
#3  0x0055c4dd in Py_Initialize () at ../Python/pythonrun.c:381
#4  0x00577805 in Py_Main (argc=5, argv=0xb684) at 
../Modules/main.c:551
#5  0x004259c8 in main (argc=5, argv=0xb684) at 
../Modules/python.c:20

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-11-01 Thread Karsten Hilbert 
> my assumption would be that something clobbers 0x6aab7c,
> which seems to be in (?) _Py_ZeroStruct in this run. I'll
> re-run a few times to make sure the corruption "reliably"
> hits _Py_ZeroStruct.
> 
> If so, I'll set a memory write breakpoint on _Py_ZeroStruct.

Interestingly, on subsequent runs, it seems to hit the same
address, 0x6aab7c, belonging to the same symbol, _Py_ZeroStruct.

This is what happens:

(gdb) watch *0x6aab7c
Hardware watchpoint 1: *0x6aab7c
(gdb) run
Starting program: /usr/bin/python2.7-dbg ./bootstrap_gm_db_system.py 
--log-file=./bootstrap-latest.log --conf-file=bootstrap-latest.conf --
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".

Hardware watchpoint 1: *0x6aab7c

Old value = 0
New value = -1208182272
_Py_AddToAllObjects (op=False, force=0) at ../Objects/object.c:70
70  ../Objects/object.c: Datei oder Verzeichnis nicht gefunden.
(gdb)

which means I'll probably have to apply the delayed
breakpoint setting strategy, or else it is just some initial
relocation at startup. Let's see what "cont" brings. The next
hit after the Python script has run until just before it
usually aborts:

Hardware watchpoint 1: *0x6aab7c

Old value = -1208182272
New value = 0
_Py_ForgetReference (op=False) at ../Objects/object.c:2255
2255in ../Objects/object.c
(gdb)

The backtrace at this point says:

(gdb) bt
#0  _Py_ForgetReference (op=False) at ../Objects/object.c:2255
#1  0x00497be0 in _Py_Dealloc (op=False) at ../Objects/object.c:2261
#2  0x004885d7 in insertdict_by_entry (mp=0xb7fc5674, 
key='dont_write_bytecode', hash=591857026, ep=0x7c5c08, value=None) at 
../Objects/dictobject.c:519
#3  0x00488857 in insertdict (mp=0xb7fc5674, key='dont_write_bytecode', 
hash=591857026, value=None) at ../Objects/dictobject.c:556
#4  0x0048910f in dict_set_item_by_hash_or_entry (
op={'setrecursionlimit': None, 'dont_write_bytecode': None, 
'getfilesystemencoding': , 
'long_info': , 'path_importer_cache': None, 'stdout': , 'getprofile': , '__stdin__': , 'version_info': , 
'exc_clear': , 'gettotalrefcount': , 'getrefcount': , 
'byteorder': 'little', '_clear_type_cache': None, 'excepthook': , 'subversion': ('CPython', '', ''), '_multiarch': None, 
'exc_type': None, 'ps1': None, '__excepthook__': , 'executable': '/usr/bin/python2.7-dbg', 'float_info': None, 
'copyright': 'Copyright (c) 2001-2017 Python Software Foundation.\nAll Rights 
Reserved.\n\nCopyright (c) 2000 BeOpen.com.\nAll Rights Reserved.\n\nCopyright 
(c) 1995-2001 Corporation for Nation...(truncated), key='dont_write_bytecode', 
hash=591857026, ep=0x0, value=None) at ../Objects/dictobject.c:795
#5  0x00489285 in PyDict_SetItem (
op={'setrecursionlimit': None, 'dont_write_bytecode': None, 
'getfilesystemencoding': , 
'long_info': , 'path_importer_cache': None, 'stdout': , 'getprofile': , '__stdin__': , 'version_info': , 
'exc_clear': , 'gettotalrefcount': , 'getrefcount': , 
'byteorder': 'little', '_clear_type_cache': None, 'excepthook': , 'subversion': ('CPython', '', ''), '_multiarch': None, 
'exc_type': None, 'ps1': None, '__excepthook__': , 'executable': '/usr/bin/python2.7-dbg', 'float_info': None, 
'copyright': 'Copyright (c) 2001-2017 Python Software Foundation.\nAll Rights 
Reserved.\n\nCopyright (c) 2000 BeOpen.com.\nAll Rights Reserved.\n\nCopyright 
(c) 1995-2001 Corporation for Nation...(truncated), key='dont_write_bytecode', 
value=None) at ../Objects/dictobject.c:848
#6  0x0049281f in _PyModule_Clear (m=) at 
../Objects/moduleobject.c:139
#7  0x0054a3ec in PyImport_Cleanup () at ../Python/import.c:540
#8  0x0055c53c in Py_Finalize () at ../Python/pythonrun.c:458
#9  0x0055fe9c in Py_Exit (sts=1) at ../Python/pythonrun.c:1783
#10 0x0055e0fc in handle_system_exit () at ../Python/pythonrun.c:1151
#11 0x0055e152 in PyErr_PrintEx (set_sys_last_vars=1) at 
../Python/pythonrun.c:1161
#12 0x0055dd5b in PyErr_Print () at ../Python/pythonrun.c:1064
#13 0x0055d61f in PyRun_SimpleFileExFlags (fp=0x7ee010, 
filename=0xb7e6 "./bootstrap_gm_db_system.py", closeit=1, flags=0xb4f4) 
at ../Python/pythonrun.c:952
#14 0x0055cc4e in PyRun_AnyFileExFlags (fp=0x7ee010, 
filename=0xb7e6 "./bootstrap_gm_db_system.py", closeit=1, flags=0xb4f4) 
at ../Python/pythonrun.c:752
#15 0x00577cb0 in Py_Main (argc=5, argv=0xb684) at 
../Modules/main.c:645
#16 0x004259c8 in main (argc=5, argv=0xb684) at 
../Modules/python.c:20

And continuing hits the SIGABRT right away:

(gdb) cont
Continuing.
Debug memory block at address p=0x6aab7c: API ''
0 bytes originally requested
The 3 pad bytes at p-3 are not all

Re: right list for SIGABRT python binary question ?

2017-11-01 Thread Karsten Hilbert 
On Wed, Nov 01, 2017 at 11:14:08AM +0100, Karsten Hilbert wrote:

> Or rather: I need to find out which "place" a given address
> refers to, check whether the changing addresses always belong
> to the same "place" between runs and _then_ map a "place" to
> its address and breakpoint that address on yet another run.
> 
> It might seem
> 
>   gdb> info symbol 
> 
> should give me the "place".

Given this:

Debug memory block at address p=0x6aab7c: API ''
0 bytes originally requested
The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb):
at p-3: 0x33 *** OUCH
at p-2: 0x47 *** OUCH
at p-1: 0x00 *** OUCH
Because memory is corrupted at the start, the count of bytes 
requested
   may be bogus, and checking the trailing pad bytes may segfault.
The 4 pad bytes at tail=0x6aab7c are not all FORBIDDENBYTE (0xfb):
at tail+0: 0x00 *** OUCH
at tail+1: 0x00 *** OUCH
at tail+2: 0x00 *** OUCH
at tail+3: 0x00 *** OUCH
The block was made by call #0 to debug malloc/realloc.
Fatal Python error: bad ID: Allocated using API '', verified using API 
'o'

Program received signal SIGABRT, Aborted.
0xb7fd9ce9 in __kernel_vsyscall ()
(gdb) info symbol 0x6aab7c
_Py_ZeroStruct in section .data of /usr/bin/python2.7-dbg
(gdb)

my assumption would be that something clobbers 0x6aab7c,
which seems to be in (?) _Py_ZeroStruct in this run. I'll
re-run a few times to make sure the corruption "reliably"
hits _Py_ZeroStruct.

If so, I'll set a memory write breakpoint on _Py_ZeroStruct.

Am I on the right track ?

Thanks,
Karsten

BTW, the backtrace for this run was ...

(gdb) bt
#0  0xb7fd9ce9 in __kernel_vsyscall ()
#1  0xb7d70dd0 in __libc_signal_restore_set (set=0xbfffee90) at 
../sysdeps/unix/sysv/linux/nptl-signals.h:79
#2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3  0xb7d72297 in __GI_abort () at abort.c:89
#4  0x0055fb74 in Py_FatalError (msg=0xb13c "bad ID: Allocated 
using API '\037', verified using API 'o'") at ../Python/pythonrun.c:1700
#5  0x00499adb in _PyObject_DebugCheckAddressApi (api=111 'o', 
p=0x6aab7c <_Py_ZeroStruct>) at ../Objects/obmalloc.c:1640
#6  0x004997a5 in _PyObject_DebugFreeApi (api=111 'o', p=0x6aab7c 
<_Py_ZeroStruct>) at ../Objects/obmalloc.c:1527
#7  0x0049964f in _PyObject_DebugFree (p=0x6aab7c <_Py_ZeroStruct>) at 
../Objects/obmalloc.c:1471
#8  0x00471043 in int_dealloc (v=0x6aab7c <_Py_ZeroStruct>) at 
../Objects/intobject.c:139

... so I could've known without "info symbol" :-)

#9  0x00497bee in _Py_Dealloc (op=False) at ../Objects/object.c:2262
#10 0x004885d7 in insertdict_by_entry (mp=0xb7fc5674, 
key='dont_write_bytecode', hash=591857026, ep=0x7c5c08, value=None) at 
../Objects/dictobject.c:519
#11 0x00488857 in insertdict (mp=0xb7fc5674, key='dont_write_bytecode', 
hash=591857026, value=None) at ../Objects/dictobject.c:556
#12 0x0048910f in dict_set_item_by_hash_or_entry (
op={
'setrecursionlimit': None,
'dont_write_bytecode': None,
'getfilesystemencoding': ,
'long_info': ,
'path_importer_cache': None,
'stdout': ,
'getprofile': ,
'__stdin__': ,
'version_info': ,
'exc_clear': , 'gettotalrefcount': 
, 'getrefcount': , 'byteorder': 'little', '_clear_type_cache': None, 'excepthook': 
, 'subversion': ('CPython', '', ''), 
'_multiarch': None, 'exc_type': None, 'ps1': None, '__excepthook__': , 'executable': '/usr/bin/python2.7-dbg', 'float_info': 
None, 'copyright': 'Copyright (c) 2001-2017 Python Software Foundation.\nAll 
Rights Reserved.\n\nCopyright (c) 2000 BeOpen.com.\nAll Rights 
Reserved.\n\nCopyright (c) 1995-2001 Corporation for Nation...(truncated), 
key='dont_write_bytecode', hash=591857026, ep=0x0, value=None
) at ../Objects/dictobject.c:795
#13 0x00489285 in PyDict_SetItem (
op={'setrecursionlimit': None, 'dont_write_bytecode': None, 
'getfilesystemencoding': , 
'long_info': , 'path_importer_cache': None, 'stdout': , 'getprofile': , '__stdin__': , 'version_info': , 
'exc_clear': , 'gettotalrefcount': , 'getrefcount': , 
'byteorder': 'little', '_clear_type_cache': None, 'excepthook': , 'subversion': ('CPython', '', ''), '_multiarch': None, 
'exc_type': None, 'ps1': None, '__excepthook__': , 'executable': '/usr/bin/python2.7-dbg', 'float_info': None, 
'copyright': 'Copyright (c) 2001-2017 Python Software Foundation.\nAll Rights 
Reserved.\n\nCopyright (c) 2000 BeOpen.com.\nAll Rights Reserved.\n\nCopyright 
(c) 1995-2001 Corporation for Nation...(truncated), key='dont_write_bytecode', 
value=None) at

Re: right list for SIGABRT python binary question ?

2017-11-01 Thread Karsten Hilbert 
On Wed, Nov 01, 2017 at 10:27:54AM +0100, Karsten Hilbert wrote:

> > >> It points to a memory corruption.
> > 
> > The i386/x64 architecture supports memory access breakpoints
> > and GDB, too, has support for this. You know the address which
> > gets corrupted. Thus, the following apporach could have a chance
> > to succeed:
> > 
> >Put a "memory write" breakpoint on the address which gets corrupted.
> >this should stop the program each time this address is written;
> >Check then the backtrace. As the address forms part of the
> >address block prologue, it should only be accessed from
> >Python's "malloc" (and "free") implementation. Any other access
> >indicates bad behaviour.
> 
> I understand. Thank you for the explanation. This may seem
> like a dumb question: the actual address that gets corrupted
> varies from run to run (it may be the same "place" in the
> code but that place gets put at a different address each
> run). Since I don't know the address of a given run, how do I
> set a break point on that address ?  It seems to me I first
> need to map the "place" to its address before the SIGABRT
> happens. How do I find out out which "place" needs to be
> mapped from the output I already have ?

Or rather: I need to find out which "place" a given address
refers to, check whether the changing addresses always belong
to the same "place" between runs and _then_ map a "place" to
its address and breakpoint that address on yet another run.

It might seem

gdb> info symbol 

should give me the "place".

Then

gdb> info address 

on another run. Or even just "watch https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-11-01 Thread Karsten Hilbert 
On Wed, Nov 01, 2017 at 09:21:46AM +0100, dieter wrote:

> >> It points to a memory corruption.
> 
> The i386/x64 architecture supports memory access breakpoints
> and GDB, too, has support for this. You know the address which
> gets corrupted. Thus, the following apporach could have a chance
> to succeed:
> 
>Put a "memory write" breakpoint on the address which gets corrupted.
>this should stop the program each time this address is written;
>Check then the backtrace. As the address forms part of the
>address block prologue, it should only be accessed from
>Python's "malloc" (and "free") implementation. Any other access
>indicates bad behaviour.

I understand. Thank you for the explanation. This may seem
like a dumb question: the actual address that gets corrupted
varies from run to run (it may be the same "place" in the
code but that place gets put at a different address each
run). Since I don't know the address of a given run, how do I
set a break point on that address ?  It seems to me I first
need to map the "place" to its address before the SIGABRT
happens. How do I find out out which "place" needs to be
mapped from the output I already have ?

(the "place" is the memory block you refer to)

Other than that I understand what you are getting at and am
willing to try.

Thanks,
Karsten

>Should your program get stopped too often (because the memory
>block is reused too often), you must find a good point in your
>program to activate the memory access breakpoint in a delayed way.
>You could use the Python debugger for this: execute significant
>parts of your program in the Python debugger; switching to
>GDB, check whether the address is already corrupted - if
>so, restart and refine the checks above in the portion of your program
>which caused the corruption. If the part in your program
>is sufficiently small, you can activate the memory access breakpoint.
>This approach may also be feasible, should you use a CPU
>without memory access breakpoints.


-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-11-01 Thread dieter 
Karsten Hilbert  writes:

> On Sat, Oct 21, 2017 at 09:31:54AM +0200, dieter wrote:
>> It points to a memory corruption.
> While running valgrind and friends is beyond my capabilitis I
> have run the problem through gdb to at least obtain a stack
> trace to see what gives:

The i386/x64 architecture supports memory access breakpoints
and GDB, too, has support for this. You know the address which
gets corrupted. Thus, the following apporach could have a chance
to succeed:

   Put a "memory write" breakpoint on the address which gets corrupted.
   this should stop the program each time this address is written;
   Check then the backtrace. As the address forms part of the
   address block prologue, it should only be accessed from
   Python's "malloc" (and "free") implementation. Any other access
   indicates bad behaviour.

   Should your program get stopped too often (because the memory
   block is reused too often), you must find a good point in your
   program to activate the memory access breakpoint in a delayed way.
   You could use the Python debugger for this: execute significant
   parts of your program in the Python debugger; switching to
   GDB, check whether the address is already corrupted - if
   so, restart and refine the checks above in the portion of your program
   which caused the corruption. If the part in your program
   is sufficiently small, you can activate the memory access breakpoint.
   This approach may also be feasible, should you use a CPU
   without memory access breakpoints.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-10-30 Thread Karsten Hilbert 
On Mon, Oct 30, 2017 at 02:02:25PM +0100, M.-A. Lemburg wrote:

> PS: Please CC me on replies as I don't regularly read c.l.p anymore.

Sure.

> >> Could you check whether you have similar import errors with
> >> other modules that have C extensions ? E.g. lxml.
> >>
> >> What you're seeing appears to be a compilation problem
> >> with Python 2.7.14 on Debian. The executable doesn't appear
> >> to export its symbols to the .so files, or only some of them.
> > 
> > Let's see:
> > ... using -dbg packages for everything, the imports work ...
> 
> Ah, so you were mixing debug packages with non-debug ones. This
> explains the import errors.

I am not sure I do.

I installed normal and -dbg packages for modules with
c extensions, say psycopg2:

python-psycopg2:
  Installiert:   2.7.3-1
  Installationskandidat: 2.7.3-1
  Versionstabelle:
 *** 2.7.3-1 990
990 http://httpredir.debian.org/debian buster/main i386 Packages
500 http://httpredir.debian.org/debian unstable/main i386 
Packages
100 /var/lib/dpkg/status
 2.6.2-1 500
500 http://httpredir.debian.org/debian stretch/main i386 
Packages
python-psycopg2-dbg:
  Installiert:   2.7.3-1
  Installationskandidat: 2.7.3-1
  Versionstabelle:
 *** 2.7.3-1 990
990 http://httpredir.debian.org/debian buster/main i386 Packages
500 http://httpredir.debian.org/debian unstable/main i386 
Packages
100 /var/lib/dpkg/status
 2.6.2-1 500
500 http://httpredir.debian.org/debian stretch/main i386 
Packages

Now, when running either python2.7 or python2.7-dbg, which
are installed alongside

python2.7-dbg:
  Installiert:   2.7.14-2
  Installationskandidat: 2.7.14-2
  Versionstabelle:
 *** 2.7.14-2 990
990 http://httpredir.debian.org/debian buster/main i386 Packages
500 http://httpredir.debian.org/debian unstable/main i386 
Packages
100 /var/lib/dpkg/status
 2.7.13-2 500
500 http://httpredir.debian.org/debian stretch/main i386 
Packages

python2.7:
  Installiert:   2.7.14-2
  Installationskandidat: 2.7.14-2
  Versionstabelle:
 *** 2.7.14-2 990
990 http://httpredir.debian.org/debian buster/main i386 Packages
500 http://httpredir.debian.org/debian unstable/main i386 
Packages
100 /var/lib/dpkg/status
 2.7.13-2 500
500 http://httpredir.debian.org/debian stretch/main i386 
Packages

the Debian version does (should ?) take care to import either
the -dbg or the normal version of modules. It seems it so
does because when I got both module versions installed I
don't get any import errors. So I don't think I am mixing, at
least not to my knowledge.

(But I still get the SIGABORT on shutdown regardless.)

> Do you just see the SIGABRT when running the debug versions or
> also with the production versions (memory management works differently
> in Python debug mode) ?

Either version fails.

Why haven't I tried running this under python3 ?  Because the
whole shebang is part of a wxPython application (GNUmed) and
there are no Debian packages for wxPython/wxPhoenix on py3 as
far as I know.

> BTW: It would help if you'd post the stack trace with symbols.
> The one you posted in one of your earlier emails only includes
> addresses.

I'd gladly comply if I knew how. This is what apt says about python2.7-dbg:

Package: python2.7-dbg
Version: 2.7.14-2
Description-en: Debug Build of the Python Interpreter (version 2.7)
 The package holds two things:
 .
 - A Python interpreter configured with --pydebug. Dynamically loaded 
modules
   are searched as _d.so first. Third party extensions need a 
separate
   build to be used by this interpreter.
 - Debug information for standard python interpreter and extensions.

So from that I conferred it does contain symbols.

I am getting a fresh run under gdb with python2.7-dbg. Maybe
you can point out where you'd have expected to see symbols
and help me figure out which -dbg package is missing on this
Debian system:

[...]
==> verifying target database schema ...
==> checking migrated data for plausibility ...
Done bootstrapping GNUmed database: We very likely succeeded.
log: 
/home/ncq/Projekte/gm-git/gnumed/gnumed/server/bootstrap/bootstrap-latest.log
Debug memory block at address p=0x6aab7c: API ''
0 bytes originally requested
The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb):
at p-3: 0x33 *** OUCH
at p-2: 0x47 *** OUCH
at p-1: 0x00 *** OUCH
Because memory is corrupted at

Re: right list for SIGABRT python binary question ?

2017-10-30 Thread M.-A. Lemburg 
n 25.10.2017 11:51, Karsten Hilbert wrote:
> On Tue, Oct 24, 2017 at 08:47:58PM +0200, M.-A. Lemburg wrote:
> 
 This error suggests that you have 32- and 64-bit versions of
 Python and mxDateTime mixed in your installation.

 Py_InitModule4 is only available in the 32-bit build of
 Python. With the 64-bit build, it's called Py_InitModule4_64.
> ...
>> Could you check whether you have similar import errors with
>> other modules that have C extensions ? E.g. lxml.
>>
>> What you're seeing appears to be a compilation problem
>> with Python 2.7.14 on Debian. The executable doesn't appear
>> to export its symbols to the .so files, or only some of them.
> 
> Let's see:
> ... using -dbg packages for everything, the imports work ...

Ah, so you were mixing debug packages with non-debug ones. This
explains the import errors.

> mx.DateTime imports fine as well (but the SIGABRT persists).

Do you just see the SIGABRT when running the debug versions or
also with the production versions (memory management works differently
in Python debug mode) ?

BTW: It would help if you'd post the stack trace with symbols.
The one you posted in one of your earlier emails only includes
addresses.

PS: Please CC me on replies as I don't regularly read c.l.p anymore.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Oct 30 2017)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-10-25 Thread Karsten Hilbert 
On Tue, Oct 24, 2017 at 08:47:58PM +0200, M.-A. Lemburg wrote:

> >> This error suggests that you have 32- and 64-bit versions of
> >> Python and mxDateTime mixed in your installation.
> >>
> >> Py_InitModule4 is only available in the 32-bit build of
> >> Python. With the 64-bit build, it's called Py_InitModule4_64.
...
> Could you check whether you have similar import errors with
> other modules that have C extensions ? E.g. lxml.
> 
> What you're seeing appears to be a compilation problem
> with Python 2.7.14 on Debian. The executable doesn't appear
> to export its symbols to the .so files, or only some of them.

Let's see:

python-lxml:
  Installiert:   4.0.0-1
  Installationskandidat: 4.0.0-1
  Versionstabelle:
 *** 4.0.0-1 990
990 http://httpredir.debian.org/debian buster/main i386 Packages
500 http://httpredir.debian.org/debian unstable/main i386 
Packages
100 /var/lib/dpkg/status
 3.7.1-1 500
500 http://httpredir.debian.org/debian stretch/main i386 
Packages
python-lxml-dbg:
  Installiert:   (keine)
  Installationskandidat: 4.0.0-1
  Versionstabelle:
 4.0.0-1 990
990 http://httpredir.debian.org/debian buster/main i386 Packages
500 http://httpredir.debian.org/debian unstable/main i386 
Packages
 3.7.1-1 500
500 http://httpredir.debian.org/debian stretch/main i386 
Packages


ncq@hermes:~$ python2.7-dbg
Python 2.7.14 (default, Sep 17 2017, 18:50:44)
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lxml
[45350 refs]
>>>

ncq@hermes:~$ python
Python 2.7.14 (default, Sep 17 2017, 18:50:44)
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lxml
>>>

Also, psycogp2 imports just fine.

Now that I have

python-egenix-mx-base-dbg:
  Installiert:   3.2.9-1
  Installationskandidat: 3.2.9-1
  Versionstabelle:
 *** 3.2.9-1 990
500 http://httpredir.debian.org/debian stretch/main i386 
Packages
990 http://httpredir.debian.org/debian buster/main i386 Packages
500 http://httpredir.debian.org/debian unstable/main i386 
Packages
100 /var/lib/dpkg/status

mx.DateTime imports fine as well (but the SIGABRT persists).

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-10-24 Thread M.-A. Lemburg 


On 22.10.2017 22:15, Karsten Hilbert wrote:
> On Sat, Oct 21, 2017 at 07:10:31PM +0200, M.-A. Lemburg wrote:
> 
>>> Running a debug build of py27 gave me a first lead: this
>>> Debian system (Testing, upgraded all the way from various
>>> releases ago) carries an incompatible mxDateTime which I'll
>>> take care of.
>>>
>>> *** You don't have the (right) mxDateTime binaries installed !
>>> Traceback (most recent call last):
>>>   File "./bootstrap_gm_db_system.py", line 87, in 
>>> from Gnumed.pycommon import gmCfg2, gmPsql, gmPG2, gmTools, gmI18N
>>>   File 
>>> "/home/ncq/Projekte/gm-git/gnumed/gnumed/Gnumed/pycommon/gmPG2.py", line 
>>> 34, in 
>>> from Gnumed.pycommon import gmDateTime
>>>   File 
>>> "/home/ncq/Projekte/gm-git/gnumed/gnumed/Gnumed/pycommon/gmDateTime.py", 
>>> line 52, in 
>>> import mx.DateTime as mxDT
>>>   File "/usr/lib/python2.7/dist-packages/mx/DateTime/__init__.py", line 
>>> 8, in 
>>> from DateTime import *
>>>   File "/usr/lib/python2.7/dist-packages/mx/DateTime/DateTime.py", line 
>>> 9, in 
>>> from mxDateTime import *
>>>   File 
>>> "/usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/__init__.py", line 
>>> 13, in 
>>> raise ImportError, why
>>> ImportError: 
>>> /usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so: 
>>> undefined symbol: Py_InitModule4
>>
>> This error suggests that you have 32- and 64-bit versions of
>> Python and mxDateTime mixed in your installation.
>>
>> Py_InitModule4 is only available in the 32-bit build of
>> Python. With the 64-bit build, it's called Py_InitModule4_64.
>>
>> Since you're getting the same error from faulthandler,
>> this is where I'd start to investigate.
>>
>> "nm" will list all exported and required symbols. As first step,
>> you should probably check the python binary for its symbols and
>> see whether it exports Py_InitModule* symbols.
> 
> Thanks for your input !
> 
> The python2.7-dbg build is 32 bits:
> 
>   root@hermes:~# nm /usr/bin/python2.7-dbg | grep Py_InitM
>   00155b9f T Py_InitModule4TraceRefs
> 
> 
>   python2.7-dbg:
> Installiert:   2.7.14-2
> Installationskandidat: 2.7.14-2
> Versionstabelle:
>*** 2.7.14-2 500
>   500 http://httpredir.debian.org/debian unstable/main i386 
> Packages
>   100 /var/lib/dpkg/status
>2.7.13-2 990
>   500 http://httpredir.debian.org/debian stretch/main i386 
> Packages
>   990 http://httpredir.debian.org/debian buster/main i386 Packages
> 
> The python2.7 build (no -dbg) does not have symbols.
> 
> mxDateTime really should be 32 bits, too:
> 
>   python-egenix-mxdatetime:
> Installiert:   3.2.9-1
> Installationskandidat: 3.2.9-1
> Versionstabelle:
>*** 3.2.9-1 990
>   500 http://httpredir.debian.org/debian stretch/main i386 
> Packages
>   990 http://httpredir.debian.org/debian buster/main i386 Packages
>   500 http://httpredir.debian.org/debian unstable/main i386 
> Packages
>   100 /var/lib/dpkg/status
> 
> Let me check the .so file:
> 
>   root@hermes:~# nm 
> /usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime_d.so  | 
> grep Py_InitM
>U Py_InitModule4TraceRefs
> 
> It seems it is - hm ...

Could you check whether you have similar import errors with
other modules that have C extensions ? E.g. lxml.

What you're seeing appears to be a compilation problem
with Python 2.7.14 on Debian. The executable doesn't appear
to export its symbols to the .so files, or only some of them.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


: Try our mxODBC.Connect Python Database Interface for free ! ::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-10-23 Thread Karsten Hilbert 
On Mon, Oct 23, 2017 at 03:26:18PM +0200, Thomas Jollans wrote:

> >> It points to a memory corruption.
> > 
> > While running valgrind and friends is beyond my capabilitis I
> > have run the problem through gdb to at least obtain a stack
> > trace to see what gives:
> 
> I wouldn't read too much into that. You know that somehow some memory
> got corrupted. You know at which point Python trips over the error - but
> that doesn't really tell you anything about how the memory initially got
> corrupted.

Thanks, I know. However, I am grasping for straws here since
I am unable to "properly" debug the python binary as such.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-10-23 Thread Thomas Jollans 
On 2017-10-23 14:23, Karsten Hilbert wrote:
> On Sat, Oct 21, 2017 at 09:31:54AM +0200, dieter wrote:
> 
>> It points to a memory corruption.
> 
> While running valgrind and friends is beyond my capabilitis I
> have run the problem through gdb to at least obtain a stack
> trace to see what gives:


I wouldn't read too much into that. You know that somehow some memory
got corrupted. You know at which point Python trips over the error - but
that doesn't really tell you anything about how the memory initially got
corrupted.

> 
>   ...
>   ==> verifying target database schema ...
>   ==> checking migrated data for plausibility ...
>   Done bootstrapping GNUmed database: We very likely succeeded.
>   log: 
> /home/ncq/Projekte/gm-git/gnumed/gnumed/server/bootstrap/bootstrap-latest.log
>   Debug memory block at address p=0x6aab7c: API ''
>   0 bytes originally requested
>   The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb):
>   at p-3: 0x33 *** OUCH
>   at p-2: 0x47 *** OUCH
>   at p-1: 0x00 *** OUCH
>   Because memory is corrupted at the start, the count of bytes 
> requested
>  may be bogus, and checking the trailing pad bytes may segfault.
>   The 4 pad bytes at tail=0x6aab7c are not all FORBIDDENBYTE (0xfb):
>   at tail+0: 0x00 *** OUCH
>   at tail+1: 0x00 *** OUCH
>   at tail+2: 0x00 *** OUCH
>   at tail+3: 0x00 *** OUCH
>   The block was made by call #0 to debug malloc/realloc.
>   Fatal Python error: bad ID: Allocated using API '', verified using API 
> 'o'
> 
>   Program received signal SIGABRT, Aborted.
>   0xb7fd9ce9 in __kernel_vsyscall ()
>   (gdb) bt
>   #0  0xb7fd9ce9 in __kernel_vsyscall ()
>   #1  0xb7d6edd0 in __libc_signal_restore_set (set=0xbfffed40) at 
> ../sysdeps/unix/sysv/linux/nptl-signals.h:79
>   #2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
>   #3  0xb7d70297 in __GI_abort () at abort.c:89
>   #4  0x0055fb74 in Py_FatalError (msg=0xbfffefec "bad ID: Allocated 
> using API '\037', verified using API 'o'") at ../Python/pythonrun.c:1700
>   #5  0x00499adb in _PyObject_DebugCheckAddressApi (api=111 'o', 
> p=0x6aab7c <_Py_ZeroStruct>) at ../Objects/obmalloc.c:1640
>   #6  0x004997a5 in _PyObject_DebugFreeApi (api=111 'o', p=0x6aab7c 
> <_Py_ZeroStruct>) at ../Objects/obmalloc.c:1527
>   #7  0x0049964f in _PyObject_DebugFree (p=0x6aab7c <_Py_ZeroStruct>) at 
> ../Objects/obmalloc.c:1471
>   #8  0x00471043 in int_dealloc (v=0x6aab7c <_Py_ZeroStruct>) at 
> ../Objects/intobject.c:139
>   #9  0x00497bee in _Py_Dealloc (op=False) at ../Objects/object.c:2262
>   #10 0x00489bad in dict_dealloc (mp=0xb7888f34) at 
> ../Objects/dictobject.c:1085
>   Python Exception  'utf-8' codec can't 
> decode bytes in position 1-2: unexpected end of data: 
>   #11 0x00497bee in _Py_Dealloc (op=) at ../Objects/object.c:2262
>   Python Exception  'utf-8' codec can't 
> decode bytes in position 1-2: unexpected end of data: 
>   #12 0x004b9ab7 in subtype_dealloc (self=) at 
> ../Objects/typeobject.c:1035
>   Python Exception  'utf-8' codec can't 
> decode bytes in position 1-2: unexpected end of data: 
>   #13 0x00497bee in _Py_Dealloc (op=) at ../Objects/object.c:2262
>   #14 0x0044dc7a in instancemethod_dealloc (im=0xb78984b4) at 
> ../Objects/classobject.c:2388
>   #15 0x00497bee in _Py_Dealloc (op= 0xb78984b4>) at ../Objects/object.c:2262
>   #16 0x004885d7 in insertdict_by_entry (mp=0xb78880d4, key='_shutdown', 
> hash=598970216, ep=0x88d6d4, value=None) at ../Objects/dictobject.c:519
>   #17 0x00488857 in insertdict (mp=0xb78880d4, key='_shutdown', 
> hash=598970216, value=None) at ../Objects/dictobject.c:556
>   #18 0x0048910f in dict_set_item_by_hash_or_entry (
>   op={'current_thread': , 
> '_BoundedSemaphore': None, 'currentThread': , 
> '_Timer': None, '_format_exc': None, 'Semaphore':  0xb789b6c4>, '_deque': None, 'activeCount': , 
> '_profile_hook': None, '_sleep': None, '_trace_hook': None, 'ThreadError': 
> , '_enumerate': None, '_start_new_thread': None, 
> 'BoundedSemaphore': , '_shutdown': None, 
> '__all__': ['activeCount', 'active_count', 'Condition', 'currentThread', 
> 'current_thread', 'enumerate', 'Event', 'Lock', 'RLock', 'Semaphore', 
> 'BoundedSemaphore', 'Thread', 'Timer', 'setprofile', 'settrace', 'local', 
> 'stack_size'], '_Event': , 'active_count': 
> , '__package__': None, '_Condition':  remote 0xb784c9e4>, '_RLock': , '_test':  at remote 0xb78a2b74>, 'local':   x6fd420>, '__doc__': "Thread modul...(truncated), key='_shutdown', 
> hash=598970216, ep=0x0, value=None) at ../Objects/dictobject.c:795
>   #19 0x00489285 in PyDict_SetItem (
>   op={'current_thread': , 
> '_BoundedSemaphore': None, 'currentThread': , 
> '_Timer': None, '_format_exc': None, 'Semaphore':  0xb789b6c4>,

Re: right list for SIGABRT python binary question ?

2017-10-23 Thread Karsten Hilbert 
On Sat, Oct 21, 2017 at 09:31:54AM +0200, dieter wrote:

> It points to a memory corruption.

While running valgrind and friends is beyond my capabilitis I
have run the problem through gdb to at least obtain a stack
trace to see what gives:

...
==> verifying target database schema ...
==> checking migrated data for plausibility ...
Done bootstrapping GNUmed database: We very likely succeeded.
log: 
/home/ncq/Projekte/gm-git/gnumed/gnumed/server/bootstrap/bootstrap-latest.log
Debug memory block at address p=0x6aab7c: API ''
0 bytes originally requested
The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb):
at p-3: 0x33 *** OUCH
at p-2: 0x47 *** OUCH
at p-1: 0x00 *** OUCH
Because memory is corrupted at the start, the count of bytes 
requested
   may be bogus, and checking the trailing pad bytes may segfault.
The 4 pad bytes at tail=0x6aab7c are not all FORBIDDENBYTE (0xfb):
at tail+0: 0x00 *** OUCH
at tail+1: 0x00 *** OUCH
at tail+2: 0x00 *** OUCH
at tail+3: 0x00 *** OUCH
The block was made by call #0 to debug malloc/realloc.
Fatal Python error: bad ID: Allocated using API '', verified using API 
'o'

Program received signal SIGABRT, Aborted.
0xb7fd9ce9 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fd9ce9 in __kernel_vsyscall ()
#1  0xb7d6edd0 in __libc_signal_restore_set (set=0xbfffed40) at 
../sysdeps/unix/sysv/linux/nptl-signals.h:79
#2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3  0xb7d70297 in __GI_abort () at abort.c:89
#4  0x0055fb74 in Py_FatalError (msg=0xbfffefec "bad ID: Allocated 
using API '\037', verified using API 'o'") at ../Python/pythonrun.c:1700
#5  0x00499adb in _PyObject_DebugCheckAddressApi (api=111 'o', 
p=0x6aab7c <_Py_ZeroStruct>) at ../Objects/obmalloc.c:1640
#6  0x004997a5 in _PyObject_DebugFreeApi (api=111 'o', p=0x6aab7c 
<_Py_ZeroStruct>) at ../Objects/obmalloc.c:1527
#7  0x0049964f in _PyObject_DebugFree (p=0x6aab7c <_Py_ZeroStruct>) at 
../Objects/obmalloc.c:1471
#8  0x00471043 in int_dealloc (v=0x6aab7c <_Py_ZeroStruct>) at 
../Objects/intobject.c:139
#9  0x00497bee in _Py_Dealloc (op=False) at ../Objects/object.c:2262
#10 0x00489bad in dict_dealloc (mp=0xb7888f34) at 
../Objects/dictobject.c:1085
Python Exception  'utf-8' codec can't 
decode bytes in position 1-2: unexpected end of data: 
#11 0x00497bee in _Py_Dealloc (op=) at ../Objects/object.c:2262
Python Exception  'utf-8' codec can't 
decode bytes in position 1-2: unexpected end of data: 
#12 0x004b9ab7 in subtype_dealloc (self=) at 
../Objects/typeobject.c:1035
Python Exception  'utf-8' codec can't 
decode bytes in position 1-2: unexpected end of data: 
#13 0x00497bee in _Py_Dealloc (op=) at ../Objects/object.c:2262
#14 0x0044dc7a in instancemethod_dealloc (im=0xb78984b4) at 
../Objects/classobject.c:2388
#15 0x00497bee in _Py_Dealloc (op=) at ../Objects/object.c:2262
#16 0x004885d7 in insertdict_by_entry (mp=0xb78880d4, key='_shutdown', 
hash=598970216, ep=0x88d6d4, value=None) at ../Objects/dictobject.c:519
#17 0x00488857 in insertdict (mp=0xb78880d4, key='_shutdown', 
hash=598970216, value=None) at ../Objects/dictobject.c:556
#18 0x0048910f in dict_set_item_by_hash_or_entry (
op={'current_thread': , 
'_BoundedSemaphore': None, 'currentThread': , 
'_Timer': None, '_format_exc': None, 'Semaphore': , '_deque': None, 'activeCount': , 
'_profile_hook': None, '_sleep': None, '_trace_hook': None, 'ThreadError': 
, '_enumerate': None, '_start_new_thread': None, 
'BoundedSemaphore': , '_shutdown': None, 
'__all__': ['activeCount', 'active_count', 'Condition', 'currentThread', 
'current_thread', 'enumerate', 'Event', 'Lock', 'RLock', 'Semaphore', 
'BoundedSemaphore', 'Thread', 'Timer', 'setprofile', 'settrace', 'local', 
'stack_size'], '_Event': , 'active_count': , '__package__': None, '_Condition': , '_RLock': , '_test': , 'local': , '__doc__': "Thread modul...(truncated), key='_shutdown', 
hash=598970216, ep=0x0, value=None) at ../Objects/dictobject.c:795
#19 0x00489285 in PyDict_SetItem (
op={'current_thread': , 
'_BoundedSemaphore': None, 'currentThread': , 
'_Timer': None, '_format_exc': None, 'Semaphore': , '_deque': None, 'activeCount': , 
'_profile_hook': None, '_sleep': None, '_trace_hook': None, 'ThreadError': 
, '_enumerate': None, '_start_new_thread': None, 
'BoundedSemaphore': , '_shutdown': None, 
'__all__': ['activeCount', 'active_count', 'Condition', 'currentThread', 
'current_thread', 'enumerate', 'Event', 'Lock', 'RLock', 'Semaphore', 
'BoundedSemaphore', 'Thread', 'Timer', 'setprofile', 'settrace', 'local', 
'stack_size'],

Re: right list for SIGABRT python binary question ?

2017-10-23 Thread Karsten Hilbert 
On Sun, Oct 22, 2017 at 11:10:33PM +0200, Karsten Hilbert wrote:

>> It points to a memory corruption.
>
> thanks for your guidance. I fear this approach is out of my class.

For what it's worth I have run a successful overnight memory
stress test (memtest86+) so it shouldn't be a bad bit in
hardware.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-10-22 Thread Karsten Hilbert 
On Sat, Oct 21, 2017 at 09:31:54AM +0200, dieter wrote:

> > Debug memory block at address p=0x717b7c: API ''
> > 0 bytes originally requested
> > The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb):
> > at p-3: 0x03 *** OUCH
> > at p-2: 0x4e *** OUCH
> > at p-1: 0x00 *** OUCH
> > Because memory is corrupted at the start, the count of bytes 
> > requested
> >may be bogus, and checking the trailing pad bytes may segfault.
> > The 4 pad bytes at tail=0x717b7c are not all FORBIDDENBYTE (0xfb):
> > at tail+0: 0x00 *** OUCH
> > at tail+1: 0x00 *** OUCH
> > at tail+2: 0x00 *** OUCH
> > at tail+3: 0x00 *** OUCH
> > The block was made by call #0 to debug malloc/realloc.
> > Fatal Python error: bad ID: Allocated using API '', verified using API 
> > 'o'
> > ...
> > Can anyone give more guidance on what the above python debug
> > output might vaguely point to ?
> 
> It points to a memory corruption.
> 
> I would approach the problem by means of debugging: put a write
> breakpoint at the corrupted address "0x717b7c" and check what part
> of the system accesses it (this assumes you are using a CPU
> supporting write breakpoints).
> It may be very tedious as the address might be accessed very often
> legally before it gets corrupted.
> 
> Another approach may be to use a tool designed for memory debugging,
> e.g. "valgrind".

Hi Dieter,

thanks for your guidance. I fear this approach is out of my class.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-10-22 Thread Karsten Hilbert 
On Sun, Oct 22, 2017 at 10:15:51PM +0200, Karsten Hilbert wrote:

> The python2.7-dbg build is 32 bits:

...

> The python2.7 build (no -dbg) does not have symbols.

More to the point:

/usr/bin/python2.7: ELF 32-bit LSB shared object, Intel 80386, version 
1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 
2.6.32, BuildID[sha1]=91226399fb434d138f166a5c8eca04385ea2e41f, stripped

/usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so: 
ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically 
linked, BuildID[sha1]=f09c7cc78b41421d3cee1f418b4d45772a3db701, stripped

Regards,
Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-10-22 Thread Karsten Hilbert 
On Sat, Oct 21, 2017 at 07:10:31PM +0200, M.-A. Lemburg wrote:

> > Running a debug build of py27 gave me a first lead: this
> > Debian system (Testing, upgraded all the way from various
> > releases ago) carries an incompatible mxDateTime which I'll
> > take care of.
> > 
> > *** You don't have the (right) mxDateTime binaries installed !
> > Traceback (most recent call last):
> >   File "./bootstrap_gm_db_system.py", line 87, in 
> > from Gnumed.pycommon import gmCfg2, gmPsql, gmPG2, gmTools, gmI18N
> >   File 
> > "/home/ncq/Projekte/gm-git/gnumed/gnumed/Gnumed/pycommon/gmPG2.py", line 
> > 34, in 
> > from Gnumed.pycommon import gmDateTime
> >   File 
> > "/home/ncq/Projekte/gm-git/gnumed/gnumed/Gnumed/pycommon/gmDateTime.py", 
> > line 52, in 
> > import mx.DateTime as mxDT
> >   File "/usr/lib/python2.7/dist-packages/mx/DateTime/__init__.py", line 
> > 8, in 
> > from DateTime import *
> >   File "/usr/lib/python2.7/dist-packages/mx/DateTime/DateTime.py", line 
> > 9, in 
> > from mxDateTime import *
> >   File 
> > "/usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/__init__.py", line 
> > 13, in 
> > raise ImportError, why
> > ImportError: 
> > /usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so: 
> > undefined symbol: Py_InitModule4
> 
> This error suggests that you have 32- and 64-bit versions of
> Python and mxDateTime mixed in your installation.
> 
> Py_InitModule4 is only available in the 32-bit build of
> Python. With the 64-bit build, it's called Py_InitModule4_64.
> 
> Since you're getting the same error from faulthandler,
> this is where I'd start to investigate.
> 
> "nm" will list all exported and required symbols. As first step,
> you should probably check the python binary for its symbols and
> see whether it exports Py_InitModule* symbols.

Thanks for your input !

The python2.7-dbg build is 32 bits:

root@hermes:~# nm /usr/bin/python2.7-dbg | grep Py_InitM
00155b9f T Py_InitModule4TraceRefs


python2.7-dbg:
  Installiert:   2.7.14-2
  Installationskandidat: 2.7.14-2
  Versionstabelle:
 *** 2.7.14-2 500
500 http://httpredir.debian.org/debian unstable/main i386 
Packages
100 /var/lib/dpkg/status
 2.7.13-2 990
500 http://httpredir.debian.org/debian stretch/main i386 
Packages
990 http://httpredir.debian.org/debian buster/main i386 Packages

The python2.7 build (no -dbg) does not have symbols.

mxDateTime really should be 32 bits, too:

python-egenix-mxdatetime:
  Installiert:   3.2.9-1
  Installationskandidat: 3.2.9-1
  Versionstabelle:
 *** 3.2.9-1 990
500 http://httpredir.debian.org/debian stretch/main i386 
Packages
990 http://httpredir.debian.org/debian buster/main i386 Packages
500 http://httpredir.debian.org/debian unstable/main i386 
Packages
100 /var/lib/dpkg/status

Let me check the .so file:

root@hermes:~# nm 
/usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime_d.so  | grep 
Py_InitM
 U Py_InitModule4TraceRefs

It seems it is - hm ...

Thanks,
Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-10-21 Thread M.-A. Lemburg 
On 17.10.2017 09:30, Karsten Hilbert wrote:
> On Tue, Oct 17, 2017 at 12:04:09PM +1100, Steve D'Aprano wrote:
> 
>>> is this the right list to ask for help in debugging a
>>> SIGABORT (?) happening on shutdown of a Python 2.7 script ?
>>>
>>> If not, which one is ?
>>
>> You should try here first.
>>
>> Please ensure you read and follow this first:
>>
>> http://sscce.org/
>>
>> and post a *minimum* example of your code. (Sorry for the redundant
>> instructions if you already know this, but you would be surprised how many
>> people don't.)
> 
> Thanks. I'll work towards a postable example.
> 
> Running a debug build of py27 gave me a first lead: this
> Debian system (Testing, upgraded all the way from various
> releases ago) carries an incompatible mxDateTime which I'll
> take care of.
> 
>   *** You don't have the (right) mxDateTime binaries installed !
>   Traceback (most recent call last):
> File "./bootstrap_gm_db_system.py", line 87, in 
>   from Gnumed.pycommon import gmCfg2, gmPsql, gmPG2, gmTools, gmI18N
> File 
> "/home/ncq/Projekte/gm-git/gnumed/gnumed/Gnumed/pycommon/gmPG2.py", line 34, 
> in 
>   from Gnumed.pycommon import gmDateTime
> File 
> "/home/ncq/Projekte/gm-git/gnumed/gnumed/Gnumed/pycommon/gmDateTime.py", line 
> 52, in 
>   import mx.DateTime as mxDT
> File "/usr/lib/python2.7/dist-packages/mx/DateTime/__init__.py", line 
> 8, in 
>   from DateTime import *
> File "/usr/lib/python2.7/dist-packages/mx/DateTime/DateTime.py", line 
> 9, in 
>   from mxDateTime import *
> File 
> "/usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/__init__.py", line 
> 13, in 
>   raise ImportError, why
>   ImportError: 
> /usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so: 
> undefined symbol: Py_InitModule4

This error suggests that you have 32- and 64-bit versions of
Python and mxDateTime mixed in your installation.

Py_InitModule4 is only available in the 32-bit build of
Python. With the 64-bit build, it's called Py_InitModule4_64.

Since you're getting the same error from faulthandler,
this is where I'd start to investigate.

"nm" will list all exported and required symbols. As first step,
you should probably check the python binary for its symbols and
see whether it exports Py_InitModule* symbols.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Oct 21 2017)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-10-21 Thread dieter 
Karsten Hilbert  writes:
> ...
> So here's the final console output of that:
> ...
>   Debug memory block at address p=0x717b7c: API ''
>   0 bytes originally requested
>   The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb):
>   at p-3: 0x03 *** OUCH
>   at p-2: 0x4e *** OUCH
>   at p-1: 0x00 *** OUCH
>   Because memory is corrupted at the start, the count of bytes 
> requested
>  may be bogus, and checking the trailing pad bytes may segfault.
>   The 4 pad bytes at tail=0x717b7c are not all FORBIDDENBYTE (0xfb):
>   at tail+0: 0x00 *** OUCH
>   at tail+1: 0x00 *** OUCH
>   at tail+2: 0x00 *** OUCH
>   at tail+3: 0x00 *** OUCH
>   The block was made by call #0 to debug malloc/realloc.
>   Fatal Python error: bad ID: Allocated using API '', verified using API 
> 'o'
> ...
> Can anyone give more guidance on what the above python debug
> output might vaguely point to ?

It points to a memory corruption.

I would approach the problem by means of debugging: put a write
breakpoint at the corrupted address "0x717b7c" and check what part
of the system accesses it (this assumes you are using a CPU
supporting write breakpoints).
It may be very tedious as the address might be accessed very often
legally before it gets corrupted.

Another approach may be to use a tool designed for memory debugging,
e.g. "valgrind".

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-10-19 Thread Karsten Hilbert 
On Thu, Oct 19, 2017 at 07:27:45PM +0200, Karsten Hilbert wrote:

> I am currently running the bootstrapper with mxdatetime as a
> dbg build to see what gives. The only other C extension I am
> aware of that is in use is psycopg2.

So here's the final console output of that:

==> bootstrapping "v20_fixups-pre_v21" ...
==> dropping pre-existing target database [gnumed_v21] ...
==> cloning [gnumed_v20] (72 MB) as target database [gnumed_v21] ...
==> reindexing target database (can take a while) ...
==> transferring users ...
==> bootstrapping "v20-v21-static" ...
==> bootstrapping "v20-v21-dynamic" ...
==> bootstrapping "v21-fixups" ...
==> setting up auditing ...
==> setting up encounter/episode FKs and IDXs ...
==> setting up encounter/episode FK sanity check triggers ...
==> setting up generic notifications ...
==> upgrading reference data sets ...
==> verifying target database schema ...
==> checking migrated data for plausibility ...
Done bootstrapping GNUmed database: We very likely succeeded.
log: 
/home/ncq/Projekte/gm-git/gnumed/gnumed/server/bootstrap/bootstrap-latest.log
Debug memory block at address p=0x717b7c: API ''
0 bytes originally requested
The 3 pad bytes at p-3 are not all FORBIDDENBYTE (0xfb):
at p-3: 0x03 *** OUCH
at p-2: 0x4e *** OUCH
at p-1: 0x00 *** OUCH
Because memory is corrupted at the start, the count of bytes 
requested
   may be bogus, and checking the trailing pad bytes may segfault.
The 4 pad bytes at tail=0x717b7c are not all FORBIDDENBYTE (0xfb):
at tail+0: 0x00 *** OUCH
at tail+1: 0x00 *** OUCH
at tail+2: 0x00 *** OUCH
at tail+3: 0x00 *** OUCH
The block was made by call #0 to debug malloc/realloc.
Fatal Python error: bad ID: Allocated using API '', verified using API 
'o'
./bootstrap-latest.sh: Zeile 80: 28023 Abgebrochen 
./bootstrap_gm_db_system.py --log-file=${LOG} --conf-file=${CONF} --${QUIET}
Bootstrapping "gnumed_v21" did not finish successfully (134). Aborting.

Note there's not faulthandler output here because I don't yet
know how to get a debug build of *that* (Debian does not seem
to have one and neither does pypi to my knowledge).

That'd be needed because of:

root@hermes:~/bin# python2.7-dbg
Python 2.7.14 (default, Sep 17 2017, 18:50:44)
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import faulthandler
Traceback (most recent call last):
  File "", line 1, in 
ImportError: 
/usr/lib/python2.7/dist-packages/faulthandler.i386-linux-gnu.so: undefined 
symbol: Py_InitModule4
[45316 refs]
>>>

Can anyone give more guidance on what the above python debug
output might vaguely point to ?

Thanks,
Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-10-19 Thread Karsten Hilbert 
On Wed, Oct 18, 2017 at 02:07:46PM +0200, Thomas Jollans wrote:

> > When run under a debug build it sayeth right away (simulated
> > as a minimal working example):
> > 
> > root@hermes:~/bin# python2.7-dbg
> > Python 2.7.14 (default, Sep 17 2017, 18:50:44)
> > [GCC 7.2.0] on linux2
> > Type "help", "copyright", "credits" or "license" for more 
> > information.
> > >>> import mx.DateTime
> > *** You don't have the (right) mxDateTime binaries installed !
> > Traceback (most recent call last):
> >   File "", line 1, in 
> >   File "/usr/lib/python2.7/dist-packages/mx/DateTime/__init__.py", 
> > line 8, in 
> > from DateTime import *
> >   File "/usr/lib/python2.7/dist-packages/mx/DateTime/DateTime.py", 
> > line 9, in 
> > from mxDateTime import *
> >   File 
> > "/usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/__init__.py", line 
> > 13, in 
> > raise ImportError, why
> > ImportError: 
> > /usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so: 
> > undefined symbol: Py_InitModule4
> 
> I don't really what exactly is going on here, but in general extension
> modules compiled for non-debug builds won't work with debug builds.

OK, that helps. I found -dbg builds of mx.DateTime in Debian.

> > For good measure I have filed a bug with Debian asking for
> > recompilation of python-egenix-mxdatetime.
> 
> Even if the maintainers do that, it won't help. Check that the module
> works on its own with the regular Python build and then close the bug if
> the maintainers don't beat you to it.

Done.

> > When run under "normal" py2.7 it runs all the way through but
> > upon shutdown (*after* sys.exit(0)) faulthandler shows a
> > problem (and returns 134 which made me think of SIGABRT):
> 
> We still don't know what "it" is.
> 
> Strip down your script as much as possible. It looks like you're using a
> lot of extension modules, and any one of them could (in theory) be
> causing problems.

I know. However, stripping down isn't quite so easy (it never
is, which is a rather lame excuse for not doing so yet :-)

The script itself is but a meager 1843 lines (but using lots
of Python modules, both stdlib and my own). What it does is
take a large number of SQL files (roughly a thousand) and
replaying them against PostgreSQL thereby bootstrapping a
database layout from scratch up to the current version (21).
The abort-on-exit only happens if "enough" SQL scripts have
been run (sounds like a resource leak) and the bootstrapper
script exits (having encountered a database problem or not
makes no difference).  Running various parts of the whole
procedure does not make a difference as to whether the fault
occurs when exiting, if only "enough" SQL scripts are run.

I am currently running the bootstrapper with mxdatetime as a
dbg build to see what gives. The only other C extension I am
aware of that is in use is psycopg2.

However, none of these two (nor any other modules) have been
added to the bootstrapper (or updated) recently (in fact,
this setup has been in use for, what, a decade?) so it is
quite unclear why they should be at fault now.

The one thing that did change is PostgreSQL going from 9.6 to
10, effecting a libpq5 recompiled against the newer PG
client. I wonder whether psycopg2 needs a recompile against
that libpq5 (despite there not having been changes advertised
by PG).

I guess I'll have to downgrade libpq5 to 9.6 and see what
happens.

I'll report what I find.

(oh, and it's all available on github)

Thanks,
Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-10-19 Thread dieter 
Karsten Hilbert  writes:
> ...
> When run under "normal" py2.7 it runs all the way through but
> upon shutdown (*after* sys.exit(0)) faulthandler shows a
> problem (and returns 134 which made me think of SIGABRT):
>
>   *** Error in `python': free(): invalid pointer: 0x00770b14 ***

This indicates some form of memory corruption, usually caused by
some C extension. Unfortunately, memory corruption is rarely noticed
locally; therefore, the localization is typically complex.

Maybe, you are lucky and the "mxdatetime" is to blame.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-10-18 Thread Thomas Jollans 
On 2017-10-18 13:43, Karsten Hilbert wrote:
> OK, here's the first bit which might be part of the puzzle of
> why my Python script SIGABRT's.
> 
> When run under "normal" py2.7 it runs all the way through but
> upon shutdown (*after* sys.exit(0)) faulthandler shows a
> problem (and returns 134 which made me think of SIGABRT):
> 
>   *** Error in `python': free(): invalid pointer: 0x00770b14 ***
>   === Backtrace: =
>   /lib/i386-linux-gnu/libc.so.6(+0x6738a)[0xb7ccc38a]
>   /lib/i386-linux-gnu/libc.so.6(+0x6dfc7)[0xb7cd2fc7]
>   /lib/i386-linux-gnu/libc.so.6(+0x6e806)[0xb7cd3806]
>   python(PyObject_Free+0xfb)[0x44affb]
>   python(+0x110b51)[0x534b51]
>   python(+0x110b51)[0x534b51]
>   python(+0x110b51)[0x534b51]
>   python(+0xf3ea7)[0x517ea7]
>   python(PyDict_SetItem+0x201)[0x4d4f81]
>   python(_PyModule_Clear+0x150)[0x539630]
>   python(PyImport_Cleanup+0x61d)[0x53927d]
>   python(Py_Finalize+0x9d)[0x53635d]
>   python(Py_Exit+0x14)[0x55cb24]
>   python(+0x136102)[0x55a102]
>   python(PyErr_PrintEx+0x35)[0x559975]
>   python(+0x3dd41)[0x461d41]
>   python(Py_Main+0x753)[0x4d2c83]
>   python(main+0x1b)[0x4d251b]
>   /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6)[0xb7c7d286]
>   python(+0xae3f3)[0x4d23f3]
>   === Memory map: 
>   00424000-00763000 r-xp  08:01 6285092/usr/bin/python2.7
>   00763000-00764000 r--p 0033e000 08:01 6285092/usr/bin/python2.7
>   00764000-007c4000 rw-p 0033f000 08:01 6285092/usr/bin/python2.7
>   007c4000-007d9000 rw-p  00:00 0 
>   026f1000-02921000 rw-p  00:00 0  [heap]
>   b680-b6821000 rw-p  00:00 0 
>   b6821000-b690 ---p  00:00 0 
>   b6995000-b69b r-xp  08:01 8151085
> /lib/i386-linux-gnu/libgcc_s.so.1
>   b69b-b69b1000 r--p 0001a000 08:01 8151085
> /lib/i386-linux-gnu/libgcc_s.so.1
>   b69b1000-b69b2000 rw-p 0001b000 08:01 8151085
> /lib/i386-linux-gnu/libgcc_s.so.1
>   b69f5000-b6b35000 rw-p  00:00 0 
>   b6b35000-b6b4 r-xp  08:01 8151337
> /lib/i386-linux-gnu/libnss_files-2.24.so
>   b6b4-b6b41000 r--p a000 08:01 8151337
> /lib/i386-linux-gnu/libnss_files-2.24.so
>   b6b41000-b6b42000 rw-p b000 08:01 8151337
> /lib/i386-linux-gnu/libnss_files-2.24.so
>   b6b42000-b6b48000 rw-p  00:00 0 
>   b6b48000-b6b53000 r-xp  08:01 8151339
> /lib/i386-linux-gnu/libnss_nis-2.24.so
>   b6b53000-b6b54000 r--p a000 08:01 8151339
> /lib/i386-linux-gnu/libnss_nis-2.24.so
>   b6b54000-b6b55000 rw-p b000 08:01 8151339
> /lib/i386-linux-gnu/libnss_nis-2.24.so
>   b6b64000-b6b6b000 r--p  08:01 6286752
> /usr/share/locale/de/LC_MESSAGES/libpq5-10.mo
>   b6b6b000-b6b72000 r--s  08:01 6903281
> /usr/lib/i386-linux-gnu/gconv/gconv-modules.cache
>   b6b72000-b6b98000 r--p  08:01 6288754
> /usr/share/locale/de/LC_MESSAGES/libc.mo
>   b6b98000-b6c98000 rw-p  00:00 0 
>   b6c9e000-b6cb4000 r-xp  08:01 8151334
> /lib/i386-linux-gnu/libnsl-2.24.so
>   b6cb4000-b6cb5000 r--p 00016000 08:01 8151334
> /lib/i386-linux-gnu/libnsl-2.24.so
>   b6cb5000-b6cb6000 rw-p 00017000 08:01 8151334
> /lib/i386-linux-gnu/libnsl-2.24.so
>   b6cb6000-b6cb8000 rw-p  00:00 0 
>   b6cb8000-b6cc r-xp  08:01 8151335
> /lib/i386-linux-gnu/libnss_compat-2.24.so
>   b6cc-b6cc1000 r--p 7000 08:01 8151335
> /lib/i386-linux-gnu/libnss_compat-2.24.so
>   b6cc1000-b6cc2000 rw-p 8000 08:01 8151335
> /lib/i386-linux-gnu/libnss_compat-2.24.so
>   b6cc2000-b6d02000 rw-p  00:00 0 
>   b6d02000-b6d09000 r-xp  08:01 6899491
> /usr/lib/i386-linux-gnu/libffi.so.6.0.4
>   b6d09000-b6d0a000 r--p 6000 08:01 6899491
> /usr/lib/i386-linux-gnu/libffi.so.6.0.4
>   b6d0a000-b6d0b000 rw-p 7000 08:01 6899491
> /usr/lib/i386-linux-gnu/libffi.so.6.0.4
>   b6d0b000-b6d96000 r-xp  08:01 6899509
> /usr/lib/i386-linux-gnu/libgmp.so.10.3.2
>   b6d96000-b6d97000 r--p 0008a000 08:01 6899509
> /usr/lib/i386-linux-gnu/libgmp.so.10.3.2
>   b6d97000-b6d98000 rw-p 0008b000 08:01 6899509
> /usr/lib/i386-linux-gnu/libgmp.so.10.3.2
>   b6d98000-b6dcc000 r-xp  08:01 6899139
> /usr/lib/i386-linux-gnu/libhogweed.so.4.3
>   b6dcc000-b6dcd000 r--p 00033000 08:01 6899139
> /usr/lib/i386-linux-gnu/libhogweed.so.4.3
>   b6dcd000-b6dce000 rw-p 00034000 08:01 6899139
> /usr/lib/i386-linux-gnu/libhogweed.so.4.3
>   b6dce000-b6e08000 r-xp  08:01 6897991
> /usr/lib/i386-linux-gnu/libnettle.so.6.3
>   b6e08000-b6e09000 ---p 0003a000 08:01 6897991
> /usr/lib/i386-linux-gnu/libnettle.so.6.3
>   b6e09000-b6e0a000 r--p 0003a000

Re: right list for SIGABRT python binary question ?

2017-10-18 Thread Karsten Hilbert 
OK, here's the first bit which might be part of the puzzle of
why my Python script SIGABRT's.

When run under "normal" py2.7 it runs all the way through but
upon shutdown (*after* sys.exit(0)) faulthandler shows a
problem (and returns 134 which made me think of SIGABRT):

*** Error in `python': free(): invalid pointer: 0x00770b14 ***
=== Backtrace: =
/lib/i386-linux-gnu/libc.so.6(+0x6738a)[0xb7ccc38a]
/lib/i386-linux-gnu/libc.so.6(+0x6dfc7)[0xb7cd2fc7]
/lib/i386-linux-gnu/libc.so.6(+0x6e806)[0xb7cd3806]
python(PyObject_Free+0xfb)[0x44affb]
python(+0x110b51)[0x534b51]
python(+0x110b51)[0x534b51]
python(+0x110b51)[0x534b51]
python(+0xf3ea7)[0x517ea7]
python(PyDict_SetItem+0x201)[0x4d4f81]
python(_PyModule_Clear+0x150)[0x539630]
python(PyImport_Cleanup+0x61d)[0x53927d]
python(Py_Finalize+0x9d)[0x53635d]
python(Py_Exit+0x14)[0x55cb24]
python(+0x136102)[0x55a102]
python(PyErr_PrintEx+0x35)[0x559975]
python(+0x3dd41)[0x461d41]
python(Py_Main+0x753)[0x4d2c83]
python(main+0x1b)[0x4d251b]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6)[0xb7c7d286]
python(+0xae3f3)[0x4d23f3]
=== Memory map: 
00424000-00763000 r-xp  08:01 6285092/usr/bin/python2.7
00763000-00764000 r--p 0033e000 08:01 6285092/usr/bin/python2.7
00764000-007c4000 rw-p 0033f000 08:01 6285092/usr/bin/python2.7
007c4000-007d9000 rw-p  00:00 0 
026f1000-02921000 rw-p  00:00 0  [heap]
b680-b6821000 rw-p  00:00 0 
b6821000-b690 ---p  00:00 0 
b6995000-b69b r-xp  08:01 8151085
/lib/i386-linux-gnu/libgcc_s.so.1
b69b-b69b1000 r--p 0001a000 08:01 8151085
/lib/i386-linux-gnu/libgcc_s.so.1
b69b1000-b69b2000 rw-p 0001b000 08:01 8151085
/lib/i386-linux-gnu/libgcc_s.so.1
b69f5000-b6b35000 rw-p  00:00 0 
b6b35000-b6b4 r-xp  08:01 8151337
/lib/i386-linux-gnu/libnss_files-2.24.so
b6b4-b6b41000 r--p a000 08:01 8151337
/lib/i386-linux-gnu/libnss_files-2.24.so
b6b41000-b6b42000 rw-p b000 08:01 8151337
/lib/i386-linux-gnu/libnss_files-2.24.so
b6b42000-b6b48000 rw-p  00:00 0 
b6b48000-b6b53000 r-xp  08:01 8151339
/lib/i386-linux-gnu/libnss_nis-2.24.so
b6b53000-b6b54000 r--p a000 08:01 8151339
/lib/i386-linux-gnu/libnss_nis-2.24.so
b6b54000-b6b55000 rw-p b000 08:01 8151339
/lib/i386-linux-gnu/libnss_nis-2.24.so
b6b64000-b6b6b000 r--p  08:01 6286752
/usr/share/locale/de/LC_MESSAGES/libpq5-10.mo
b6b6b000-b6b72000 r--s  08:01 6903281
/usr/lib/i386-linux-gnu/gconv/gconv-modules.cache
b6b72000-b6b98000 r--p  08:01 6288754
/usr/share/locale/de/LC_MESSAGES/libc.mo
b6b98000-b6c98000 rw-p  00:00 0 
b6c9e000-b6cb4000 r-xp  08:01 8151334
/lib/i386-linux-gnu/libnsl-2.24.so
b6cb4000-b6cb5000 r--p 00016000 08:01 8151334
/lib/i386-linux-gnu/libnsl-2.24.so
b6cb5000-b6cb6000 rw-p 00017000 08:01 8151334
/lib/i386-linux-gnu/libnsl-2.24.so
b6cb6000-b6cb8000 rw-p  00:00 0 
b6cb8000-b6cc r-xp  08:01 8151335
/lib/i386-linux-gnu/libnss_compat-2.24.so
b6cc-b6cc1000 r--p 7000 08:01 8151335
/lib/i386-linux-gnu/libnss_compat-2.24.so
b6cc1000-b6cc2000 rw-p 8000 08:01 8151335
/lib/i386-linux-gnu/libnss_compat-2.24.so
b6cc2000-b6d02000 rw-p  00:00 0 
b6d02000-b6d09000 r-xp  08:01 6899491
/usr/lib/i386-linux-gnu/libffi.so.6.0.4
b6d09000-b6d0a000 r--p 6000 08:01 6899491
/usr/lib/i386-linux-gnu/libffi.so.6.0.4
b6d0a000-b6d0b000 rw-p 7000 08:01 6899491
/usr/lib/i386-linux-gnu/libffi.so.6.0.4
b6d0b000-b6d96000 r-xp  08:01 6899509
/usr/lib/i386-linux-gnu/libgmp.so.10.3.2
b6d96000-b6d97000 r--p 0008a000 08:01 6899509
/usr/lib/i386-linux-gnu/libgmp.so.10.3.2
b6d97000-b6d98000 rw-p 0008b000 08:01 6899509
/usr/lib/i386-linux-gnu/libgmp.so.10.3.2
b6d98000-b6dcc000 r-xp  08:01 6899139
/usr/lib/i386-linux-gnu/libhogweed.so.4.3
b6dcc000-b6dcd000 r--p 00033000 08:01 6899139
/usr/lib/i386-linux-gnu/libhogweed.so.4.3
b6dcd000-b6dce000 rw-p 00034000 08:01 6899139
/usr/lib/i386-linux-gnu/libhogweed.so.4.3
b6dce000-b6e08000 r-xp  08:01 6897991
/usr/lib/i386-linux-gnu/libnettle.so.6.3
b6e08000-b6e09000 ---p 0003a000 08:01 6897991
/usr/lib/i386-linux-gnu/libnettle.so.6.3
b6e09000-b6e0a000 r--p 0003a000 08:01 6897991
/usr/lib/i386-linux-gnu/libnettle.so.6.3
b6e0a000-b6e0b000 rw-p 0003b000 08:01 6897991

Re: right list for SIGABRT python binary question ?

2017-10-17 Thread Karsten Hilbert 
On Tue, Oct 17, 2017 at 12:04:09PM +1100, Steve D'Aprano wrote:

> > is this the right list to ask for help in debugging a
> > SIGABORT (?) happening on shutdown of a Python 2.7 script ?
> > 
> > If not, which one is ?
> 
> You should try here first.
> 
> Please ensure you read and follow this first:
> 
> http://sscce.org/
> 
> and post a *minimum* example of your code. (Sorry for the redundant
> instructions if you already know this, but you would be surprised how many
> people don't.)

Thanks. I'll work towards a postable example.

Running a debug build of py27 gave me a first lead: this
Debian system (Testing, upgraded all the way from various
releases ago) carries an incompatible mxDateTime which I'll
take care of.

*** You don't have the (right) mxDateTime binaries installed !
Traceback (most recent call last):
  File "./bootstrap_gm_db_system.py", line 87, in 
from Gnumed.pycommon import gmCfg2, gmPsql, gmPG2, gmTools, gmI18N
  File 
"/home/ncq/Projekte/gm-git/gnumed/gnumed/Gnumed/pycommon/gmPG2.py", line 34, in 

from Gnumed.pycommon import gmDateTime
  File 
"/home/ncq/Projekte/gm-git/gnumed/gnumed/Gnumed/pycommon/gmDateTime.py", line 
52, in 
import mx.DateTime as mxDT
  File "/usr/lib/python2.7/dist-packages/mx/DateTime/__init__.py", line 
8, in 
from DateTime import *
  File "/usr/lib/python2.7/dist-packages/mx/DateTime/DateTime.py", line 
9, in 
from mxDateTime import *
  File 
"/usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/__init__.py", line 13, 
in 
raise ImportError, why
ImportError: 
/usr/lib/python2.7/dist-packages/mx/DateTime/mxDateTime/mxDateTime.so: 
undefined symbol: Py_InitModule4

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-10-16 Thread Steve D'Aprano 
On Tue, 17 Oct 2017 07:32 am, Karsten Hilbert wrote:

> Hi all,
> 
> is this the right list to ask for help in debugging a
> SIGABORT (?) happening on shutdown of a Python 2.7 script ?
> 
> If not, which one is ?
> 
> Karsten

You should try here first.

Please ensure you read and follow this first:

http://sscce.org/


and post a *minimum* example of your code. (Sorry for the redundant
instructions if you already know this, but you would be surprised how many
people don't.)


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list