Corrputed stacktrace?


Nikolaus Rath


I'm trying to debug a problem. As far as I can tell, one of my methods
is called at a point where it really should not be called. When setting
a breakpoint in the function, I'm getting this:
-> if not self.md5_checked:
(Pdb) bt
-> self._bootstrap_inner()
-> self._target(*self._args, **self._kwargs)
-> self.finish_request(request, client_address)
-> self.RequestHandlerClass(request, client_address, self)
-> self.handle()
-> return super().handle()
-> self.handle_one_request()
-> method()
-> q = parse_url(self.path)
-> p.params = urllib.parse.parse_qs(q.query)
-> encoding=encoding, errors=errors)
-> pairs = [s2 for s1 in qs.split('&') for s2 in s1.split(';')]
-> pairs = [s2 for s1 in qs.split('&') for s2 in s1.split(';')]
-> self.fh.close()
-> if not self.md5_checked:

To me this does not make any sense.

Firstly, the thread that is (apparently) calling close should never ever
reach code in This thread is executing a socketserver handler
that is entirely contained in and only communicates with
the rest of the program via tcp.

Secondly, the backtrace does not make sense. How can evaluation of

pairs = [s2 for s1 in qs.split('&') for s2 in s1.split(';')]

in urllib/ result in a method call in backends/
There is no trickery going on, qs is a regular string:

(Pdb) up
(Pdb) up
(Pdb) up
(Pdb) l
580 into Unicode characters, as accepted by the bytes.decode() method.
582 Returns a list, as G-d intended.
583 """
584 qs, _coerce_result = _coerce_args(qs)
585 -> pairs = [s2 for s1 in qs.split('&') for s2 in s1.split(';')]
586 r = []
587 for name_value in pairs:
588 if not name_value and not strict_parsing:
589 continue
590 nv = name_value.split('=', 1)
(Pdb) whatis qs
<class 'str'>
(Pdb) p qs

I have also tried to get a backtrace with the faulthandler module, but
it gives the same result:

Thread 0x00007f7dafdb4700:
File "/usr/lib/python3.3/", line 126 in cmdloop
File "/usr/lib/python3.3/", line 318 in _cmdloop
File "/usr/lib/python3.3/", line 345 in interaction
File "/usr/lib/python3.3/", line 266 in user_line
File "/usr/lib/python3.3/", line 65 in dispatch_line
File "/usr/lib/python3.3/", line 47 in trace_dispatch
File "/home/nikratio/in-progress/s3ql/src/s3ql/backends/", line 693in clos
File "/home/nikratio/in-progress/s3ql/src/s3ql/backends/", line 853 in c
File "/usr/lib/python3.3/urllib/", line 585 in <listcomp>
File "/usr/lib/python3.3/urllib/", line 585 in parse_qsl
File "/usr/lib/python3.3/urllib/", line 553 in parse_qs
File "/home/nikratio/in-progress/s3ql/tests/", line 52 in parse_url
File "/home/nikratio/in-progress/s3ql/tests/", line 169 in do_GET
File "/usr/lib/python3.3/http/", line 388 in handle_one_request
File "/usr/lib/python3.3/http/", line 402 in handle
File "/home/nikratio/in-progress/s3ql/tests/", line 77 in handle
File "/usr/lib/python3.3/", line 666 in __init__
File "/usr/lib/python3.3/", line 345 in finish_request
File "/usr/lib/python3.3/", line 610 in process_request_thread
File "/usr/lib/python3.3/", line 858 in run
File "/usr/lib/python3.3/", line 901 in _bootstrap_inner
File "/usr/lib/python3.3/", line 878 in _bootstrap

Is it possible that the stack got somehow corrupted?

Does anyone have a suggestion how I could go about debugging this?

I am using Python 3.3.



Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question