| msg144408 - (view) |
Author: Balachandran Sivakumar (Balachandran.Sivakumar) |
Date: 2011-09-22 13:56 |
| From the python 2.6.6 interpreter on Debian Lenny(Debian 5.0), on invoking help(), and issuing the modules command, the interpreter seg faults, and dumps core. Also, it throws a few Deprecated warnings for modules like md5. The gdb backtrace on the core had 1 frame. attaching the bt in a separate file. Core was generated by `python'. Program terminated with signal 11, Segmentation fault. #0 0xb5d72e47 in XQueryExtension () from /usr/lib/libX11.so.6 (gdb) |
|
|
| msg144410 - (view) |
Author: Ezio Melotti (ezio.melotti) *  |
Date: 2011-09-22 17:59 |
| help("modules") imports all the modules, and you probably have some module that once imported makes the interpreter crash (maybe _keybinder? you could try importing that from the interpreter and see if it crashes). The deprecation warnings comes from deprecated modules that get imported too, maybe these could be silenced by help(). I'm not sure there's much we can do with this though, see also #12902. |
|
|
| msg144411 - (view) |
Author: Balachandran Sivakumar (Balachandran.Sivakumar) |
Date: 2011-09-22 18:08 |
| But this doesn't happen in other versions of python. Also what I did is something like this: bala@bala$ python ... ... >>> help() ... ... ... help > modules It is after this I see it dumping. And I see this only with 2.6.6. I have other versions in other machines(all running Debian) and none of them crash. In my opinion, a seg fault doesn't look good. Of course, if we can't do much about it, I don't have a problem closing it down. core But a segv looks bad to the beginner, who is more likely to use this. In fact, I was using that just to show a beginner how to get help :( |
|
|
| msg144412 - (view) |
Author: Ezio Melotti (ezio.melotti) * |
Date: 2011-09-22 18:46 |
| Doing "help('modules')" and "help(), help> modules" should be the same. My point is that the crash is not Python's fault, but it's caused by some extension module that gets imported by help('modules'). This module is probably not installed on the other machines and on the same machine for other Python versions, so it doesn't crash there. You can look on sys.path to see the places where Python searches for the modules. If you manage to identify the module, you could report the problem to their bug tracker. AFAIK Python can't do anything to prevent/contain a crash while importing an extension module. |
|
|
| msg145472 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2011-10-13 16:58 |
| Unless I’m mistaken, this is another of the duplicate reports for the bug fixed by Ned in 2.7 recently. |
|
|
| msg145483 - (view) |
Author: Ned Deily (ned.deily) * |
Date: 2011-10-13 19:39 |
| The recent fixes do not address cases like here where importing a module causes a crash in the interpreter process, usually due to some faulty third-party extension module. One way to handle it more gracefully might be to move the import scan to a separate interpreter subprocess. |
|
|
| msg231995 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2014-12-02 13:42 |
| I suggest to close this issue as caused by a bug in third party extension. |
|
|
| msg232058 - (view) |
Author: Terry J. Reedy (terry.reedy) * |
Date: 2014-12-02 23:11 |
| I would close this anyway, but 2.6 is no longer maintained even for security patches. |
|
|