[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: ldd return value check committed in r82927, r82928, r82929 and r82930. Thanks for reporting this! -- status: open -> closed ___ Python tracker __

[issue7384] curses crash on FreeBSD

Arfrever Frehtes Taifersar Arahesis added the comment: This patch allows to build Python 3.* in this locale. It might be safer to open tmpfile in binary mode to avoid potential problems with non-ASCII characters in paths to libraries. -- ___ Python

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: So you have garbage from stderr in readline_termcap_lib. Since that's useless anyway (no matter what locale is set), let's check the return value of os.system(). The attached patch skips readline linkage detection if ldd fails. In that case, linking will be done i

[issue7384] curses crash on FreeBSD

STINNER Victor added the comment: > "In lt_LT.UTF-8 locale, readline_termcap_lib file contains: > ne dinaminis paleidžiamasis failas" You can run ldd without LANG variable to get the original (english, ascii only) message. -- ___ Python tracker <

[issue7384] curses crash on FreeBSD

Arfrever Frehtes Taifersar Arahesis added the comment: You shouldn't use ldd. I suggest that setup.py try to link a small executable, which would use a function from libcurses and would be linked against libreadline, but not libcurses. If linking succeeds, then you libreadline is linked again

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: In Ubuntu I can build just fine with lt_LT.UTF-8. So perhaps this problem should be addressed in Gentoo. -- ___ Python tracker ___

[issue7384] curses crash on FreeBSD

Arfrever Frehtes Taifersar Arahesis added the comment: These changes break building of Python 3.* in some locales in Gentoo. running build running build_ext Traceback (most recent call last): File "./setup.py", line 1812, in main() File "./setup.py", line 1807, in main "Tools/scrip

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: Committed a conservative version implementing part 1) in r82017 (2.6) and r82019 (3.1). Part 2) can be enabled by uncommenting a couple of lines in setup.py. The buildbots look good, but I'm setting this to 'pending' in case someone would like part 2) of the fix i

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: Committed in r81669,r81672,r81683 (trunk) and r81830,81831 (py3k). What to do with the releases? To recap, the fix is: 1) Detect if readline is already linked against ncurses and if so, skip any further selection. This must be done. 2) Use the same ver

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: Mark, thanks. Committed in r81669; I'll keep an eye on the buildbots. -- ___ Python tracker ___ ___ Pyt

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: > I think it would be nice to get this into 2.7. Agreed. I think you should go ahead and commit it. -- ___ Python tracker ___

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: I think it would be nice to get this into 2.7. I don't expect buildbot failures, since the 2.7 patch is essentially the same as the py3k version, which has been tested extensively. -- Added file: http://bugs.python.org/file17528/issue7384-5-trunk.patch __

[issue7384] curses crash on FreeBSD

STINNER Victor added the comment: I tested issue7384-5-py3k.patch on FreeBSD 8.0: it fixes the crash. -- nosy: +haypo ___ Python tracker ___ _

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: Jeroen Ruigrok van der Werven wrote: > Stefan, I was emailing with Rong-En Fan, a FreeBSD committer, about this > issue and he asked: > > "Basically, this is caused by > > a) our readline.so is linked against ncurses.so (via -ltermcap which is the > same lib)

[issue7384] curses crash on FreeBSD

Jeroen Ruigrok van der Werven added the comment: Stefan, I was emailing with Rong-En Fan, a FreeBSD committer, about this issue and he asked: "Basically, this is caused by a) our readline.so is linked against ncurses.so (via -ltermcap which is the same lib) b) wide-character enabled ncur

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: Roumen Petrov wrote: > Yes , I understand . > For the protocol did gcc on FreeBSD warn if library order is -lncursesw > -lreadline ? No. > P.S. Issue with readline library linked to termcap compatible library on > system that distribute more then one termc

[issue7384] curses crash on FreeBSD

Roumen Petrov added the comment: Yes , I understand . For the protocol did gcc on FreeBSD warn if library order is -lncursesw -lreadline ? Forget for Also I'm not able to write C test case similar to python msg103231 by Mark Dickinson that fail on system where readline library is not link

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: Sigh. xxx.c == test_readline.c in the previous comment. -- ___ Python tracker ___ ___ Python-bugs-list

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: I'm not against sorting things out in configure.in, but I'm not quite sure that it will be more portable than ldd: On FreeBSD (the problem system!) I can't get this to work: [ste...@freebsd-i386 ~]$ echo 'int main() { readline(); }' > test_readline.c [ste...@free

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: I included the test for libtinfo in the latest patch. The patch is tested on Fedora and correctly links the curses module with -lncursesw. This means that the ldd method works on all buildbots, OpenBSD, OpenSolaris and Fedora. -- Added file: http://bugs.p

[issue7384] curses crash on FreeBSD

Roumen Petrov added the comment: Stefan Krah wrote: > > Stefan Krah added the comment: > > Actually this means that we should also look for -ltinfo in the ldd > check (A Redhat buildbot would be nice). Or may be this mean that in configure to add test with -ltinfo and if readline link succeed

[issue7384] curses crash on FreeBSD

Roumen Petrov added the comment: > Roumen, I do not see a line in configure.in that tests for the > libraries that readline is linked against. The test in configure is how to link application to readline libs. Platforms that support linking of shared libraries with unresolved symbols cannot l

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: Actually this means that we should also look for -ltinfo in the ldd check (A Redhat buildbot would be nice). -- ___ Python tracker ___

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: Yes, readline uses only the termcap part of ncurses. I think that --with-termlib is the correct option, see: http://www.mail-archive.com/util-linux...@vger.kernel.org/msg00273.html -- ___ Python tracker

[issue7384] curses crash on FreeBSD

Jeroen Ruigrok van der Werven added the comment: I did some digging on my side, the fact you see ncurses referenced from readline is due to the build linking readline to libtermcap: cc -fstack-protector -shared -Wl,-x -o libreadline.so.8 -Wl,-soname,libreadline.so.8 `lorder readline.So vi_

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: Mark, thanks for reviewing the patch. In the new patch, I added a skip for OS X. Buildbot testing looks good. In particular, one FreeBSD bot passes test_curses now (the other one is hanging in multiprocessing). For most bots nothing changes. The solaris bot has t

[issue7384] curses crash on FreeBSD

Roumen Petrov added the comment: Instead to test in setup.py we could use result from configure script - just uncomment line and use it -- nosy: +rpetrov ___ Python tracker ___

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: This patch looks good to me, assuming that the buildbots are happy. I agree that this seems like a sensible solution for now, even if it means limiting users to ncurses rather than ncursesw. I was initially a bit surprised that it works on OS X, since OS X d

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: Jeroen, thanks for the idea. I asked Thomas Dickey and he said that one should not load both libncurses.so and libncursesw.so. I think this means that if libreadline.so is already linked against libncurses.so, we are stuck with libncurses.so for the curses module.

[issue7384] curses crash on FreeBSD

Jeroen Ruigrok van der Werven added the comment: Just to state the obvious: ncursesw is needed for wide character support (i.e. Unicode). Also, have you tried asking Thomas Dickey (dic...@invisible-island.net) about this? He might be able to give some clue about it since he's the main curses

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: To clarify a couple of things: On some systems (Redhat?) readline is not linked against ncurses in order to give the user the possibility to choose. This is why setup.py has to select an ncurses version. However, things can go wrong if readline is already linked

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: That patch works for me, too. Nice! > It seems that FreeBSD has problems with the fact that readline.so is > linked with -lreadline and -lncursesw (why?). Good question... -- ___ Python tracker

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: It seems that FreeBSD has problems with the fact that readline.so is linked with -lreadline and -lncursesw (why?). With issue7384.patch I get no more errors using either Mark's test case or test_curses.py. -- Added file: http://bugs.python.org/file16963/i

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: Alas, after installing curses from /usr/ports/devel/ncurses I did not recompile Modules/_curses_panel.c. So, after a proper build ./python Lib/test/regrtest.py -uall test_curses shows no errors. -- ___ Python trac

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: I take that back. With the curses from /usr/ports/devel/ncurses, Mark's test case is fine, but ./python Lib/test/regrtest.py -uall test_curses fails again. -- ___ Python tracker

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: One oddity: In Mark's test case, the error only shows if readline is imported _before_ curses. The other way around it's fine. On FreeBSD 8.0 amd64, with the _default_ libcurses, the Valgrind output for py3k looks like this: [...] ==31089== Invalid write of size

[issue7384] curses crash on FreeBSD

Stefan Krah added the comment: Valgrind can be installed by: cd /usr/ports/devel/valgrind && make install Then you can do (curses_test.py is your short test program): 1) valgrind --db-attach=yes --suppressions=Misc/valgrind-python.supp ./python curses_test.py 2) valgrind --suppressions=Mis

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: > Mark, did your initial backtrace look like this: No; the segfault was definitely happening in delwin rather than putwin. But I did see something like your backtrace when I tried to use ncurses from ports (installed in /usr/local) rather than the system nc

[issue7384] curses crash on FreeBSD

Jeroen Ruigrok van der Werven added the comment: For the record, this happens on FreeBSD 8 as well. It seems it is still the same bug as what I reported back in March 2009 on the Python-dev list. If you run the test stand-alone with ./python Lib/test/regrtest.py -uall test_curses it passes a

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: 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 s

[issue7384] curses crash on FreeBSD

Changes by Jeroen Ruigrok van der Werven : -- nosy: +asmodai ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: > Here's a possible patch Thanks. I'll give it a try on my FreeBSD VM and report back. BTW, did you mean to include the threading change in that patch? -- ___ Python tracker

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: > Could I get a login on the buildbot to make a fix? I think David Bolen (db3l) is the maintainer. David? -- ___ Python tracker ___ __

[issue7384] curses crash on FreeBSD

A.M. Kuchling added the comment: Here's a possible patch; it at least doesn't seem to break the module on MacOS, though MacOS doesn't crash with the current code either. -- keywords: +patch Added file: http://bugs.python.org/file16935/freebsd-curses.diff __

[issue7384] curses crash on FreeBSD

A.M. Kuchling added the comment: Could I get a login on the buildbot to make a fix? I bet the problem is with the stdscr object. PyCurses_InitScr() does 'return (PyObject *)PyCursesWindow_New(stdscr);'. PyCursesWindow_Dealloc() does: if (wo->win != stdscr) delwin(wo->win); I bet FreeBSD is

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: Here's the top of the backtrace. (Thanks asmodai for helping me out with working out how to build a FreeBSD system ncurses with debugging information.) #0 0x000801460714 in cannot_delete (win=0x80116b1d0) at /usr/src/lib/ncurses/ncursesw/../../../co

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: I'm looking at this again, after installing FreeBSD 8.0/amd64 in a VM. I've reduced Lib/test/test_curses.py to the following 9 lines: import rlcompleter import curses f = open('mytempfile', 'w+b') stdscr = curses.initscr() stdscr.putwin(f) f.seek(0) curses.get

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: > It does appear that curses itself is broken on FreeBSD Rereading this, it doesn't say what I meant it to say: I meant that the Python curses module seems to be broken, not that the system-level curses library is broken (though that seems possible too). --

[issue7384] curses crash on FreeBSD

R. David Murray added the comment: Given your diagnosis so far, +1 on the skip. -- nosy: +r.david.murray ___ Python tracker ___ ___ Py

[issue7384] curses crash on FreeBSD

Mark Dickinson added the comment: I've not had any success tracking the cause of this failure down, and no longer have the resources to do so. It does appear that curses itself is broken on FreeBSD: it's not just a problem with the tests. Adding Andrew Kuchling to the nosy in case he has an