Message103267
With that patch, I'm still getting the core dump (with the traceback looking pretty much as it did before).
When I traced through this with gdb, I didn't see stdscr getting set to 0 at any point. Unless I missed any, the only curses library calls made (in sequence) were:
1. initscr() -> new window win (=stdscr, presumably)
2. putwin(file, win)
3. getwin(file) -> new window win2, with win2 != win
4. freewin(win2) -> segfault
---
and presumably without the segfault, there would have been calls
to freewin(win) and endwin() too.
And I'm at a complete loss to explain why importing rlcompleter makes a difference. (importing readline also causes the segfault). I don't think it's just to do with random memory changes, since if I replace the readline or rlcompleter import by any other randomly chosen python module then there's no segfault. |
|
Date |
User |
Action |
Args |
2010-04-15 22:20:10 | mark.dickinson | set | recipients:
+ mark.dickinson, akuchling, asmodai, r.david.murray |
2010-04-15 22:20:10 | mark.dickinson | set | messageid: <1271370010.46.0.896341346348.issue7384@psf.upfronthosting.co.za> |
2010-04-15 22:20:09 | mark.dickinson | link | issue7384 messages |
2010-04-15 22:20:08 | mark.dickinson | create | |
|