This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients akuchling, asmodai, mark.dickinson, r.david.murray
Date 2010-04-15.22:20:08
SpamBayes Score 8.145977e-07
Marked as misclassified No
Message-id <1271370010.46.0.896341346348.issue7384@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2010-04-15 22:20:10mark.dickinsonsetrecipients: + mark.dickinson, akuchling, asmodai, r.david.murray
2010-04-15 22:20:10mark.dickinsonsetmessageid: <1271370010.46.0.896341346348.issue7384@psf.upfronthosting.co.za>
2010-04-15 22:20:09mark.dickinsonlinkissue7384 messages
2010-04-15 22:20:08mark.dickinsoncreate