Issue639022
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.
Created on 2002-11-15 18:09 by meldh, last changed 2022-04-10 16:05 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
directory.list | meldh, 2002-11-16 10:36 | Directory listing for /usr/local/lib/python2.2 | ||
compileall.diff | loewis, 2002-11-16 14:35 | |||
diffed-log.gz | meldh, 2002-11-16 15:59 | Gzipped log file from diffed version | ||
strace-log.gz | meldh, 2002-11-17 22:38 | strace make install > log >& log | ||
logs.tgz | meldh, 2002-11-18 13:35 | Log files from ./configure, make, make test | ||
library-list.txt | meldh, 2002-11-18 23:24 | /sbin/ldconfig -p | ||
1911-test.log | meldh, 2002-11-19 11:20 | log from 'make install' | ||
test-os.log | meldh, 2002-11-19 14:17 | output of test with test_os.py | ||
gdb.log | meldh, 2002-11-19 14:45 | gdb log from os.listdir | ||
gdb-step.log | meldh, 2002-11-19 18:28 | output from gdb, stepping through posix_listdir | ||
gdb4-log.gz | meldh, 2002-11-19 19:01 | Stepping through PyString_FromStringAndSize too | ||
l.c | loewis, 2002-11-19 22:44 | |||
l1.i | meldh, 2002-11-19 23:33 | l1.i - preprocessor version without defines | ||
l2.i | meldh, 2002-11-19 23:34 | l2.i - preprocessor version with defines |
Messages (61) | |||
---|---|---|---|
msg13237 - (view) | Author: Mel (meldh) | Date: 2002-11-15 18:09 | |
./configure -- works make -- works make test -- works make install -- gets as far as trying to do this: PYTHONPATH=/usr/local/lib/python2.2 \ ./python -tt /usr/local/lib/python2.2/compileall.py -x badsyntax \ /usr/local/lib/python2.2 Listing /usr/local/lib/python2.2 ... Listing /usr/local/lib/python2.2/ ... and then goes off into infinite loop, repeating the last line until Ctrl- C. Debian 2.2 (potato), 2.2.18pre21 kernel version. |
|||
msg13238 - (view) | Author: Neal Norwitz (nnorwitz) * | Date: 2002-11-15 23:09 | |
Logged In: YES user_id=33168 Are you sure you let the process finish? It looks like there are at least 2 passes. One to generate .pyc files and the other to generate .pyo (optimized) files. There are a lot of files to run through. Does it only print the "Listing /usr/local/lib/python2.2 ... " lines and nothing in between? Could you save the output and attach it to this bug report? |
|||
msg13239 - (view) | Author: Mel (meldh) | Date: 2002-11-15 23:22 | |
Logged In: YES user_id=649744 It definitely isn't printing out anything else except the 'Listing...' line. I can let it run for a few minutes and see if it's printing that one-per-file or something, instead of just looping... hang on. |
|||
msg13240 - (view) | Author: Mel (meldh) | Date: 2002-11-15 23:23 | |
Logged In: YES user_id=649744 It definitely isn't printing out anything else except the 'Listing...' line. I can let it run for a few minutes and see if it's printing that one-per-file or something, instead of just looping... hang on. |
|||
msg13241 - (view) | Author: Mel (meldh) | Date: 2002-11-15 23:34 | |
Logged In: YES user_id=649744 Here's the log file. I let it run for about 10000 repeats and then killed it - there may be a lot of files, but _that_ many? |
|||
msg13242 - (view) | Author: Mel (meldh) | Date: 2002-11-15 23:38 | |
Logged In: YES user_id=649744 Log file now attached, gzipped |
|||
msg13243 - (view) | Author: Mel (meldh) | Date: 2002-11-15 23:38 | |
Logged In: YES user_id=649744 Log file now attached, gzipped |
|||
msg13244 - (view) | Author: Neal Norwitz (nnorwitz) * | Date: 2002-11-15 23:40 | |
Logged In: YES user_id=33168 There's no file. You have to click the checkbox next to "Check to Upload and Attach a File" in addition to entering the filename. |
|||
msg13245 - (view) | Author: Mel (meldh) | Date: 2002-11-15 23:43 | |
Logged In: YES user_id=649744 Yeah, I tried that. In between the problems with file sizes, file names and the like, it doesn't seem to have worked. I'm giving it another go now. |
|||
msg13246 - (view) | Author: Mel (meldh) | Date: 2002-11-15 23:44 | |
Logged In: YES user_id=649744 I give in, it just doesn't want to let me attach the file. It has about 10000 repeats of that same 'Listing' line, in any case. |
|||
msg13247 - (view) | Author: Neal Norwitz (nnorwitz) * | Date: 2002-11-15 23:48 | |
Logged In: YES user_id=33168 Ok, could you paste a few listing lines and about 20 or so before that. Did you try running the command from the shell? Something like: PYTHONPATH=/usr/local/lib/python2.2 \ ./python -tt /usr/local/lib/python2.2/compileall.py \ -x badsyntax /usr/local/lib/python2.2 Does that do the same thing? Is it possible there is a symlink in /usr/local/lib/python2.2 to the same directory (or .)? |
|||
msg13248 - (view) | Author: Mel (meldh) | Date: 2002-11-15 23:57 | |
Logged In: YES user_id=649744 Sure. (attached at end) Running the command from the shell does seem to do the same thing. There is no obvious symlink within /usr/local/lib/python2.2 (if a directory listing would be useful, let me know) Log excerpt: /usr/bin/install -c -m 644 ./Lib/distutils/command/install_scripts.py /usr/local/lib /python2.2/distutils/command /usr/bin/install -c -m 644 ./Lib/distutils/command/sdist.py /usr/local/lib/python2 .2/distutils/command /usr/bin/install -c -m 644 ./Lib/xml/__init__.py /usr/local/lib/python2.2/xml /usr/bin/install -c -m 644 ./Lib/xml/dom/__init__.py /usr/local/lib/python2.2/xml/ dom /usr/bin/install -c -m 644 ./Lib/xml/dom/domreg.py /usr/local/lib/python2.2/xml/ dom /usr/bin/install -c -m 644 ./Lib/xml/dom/minidom.py /usr/local/lib/python2.2/xml /dom /usr/bin/install -c -m 644 ./Lib/xml/dom/pulldom.py /usr/local/lib/python2.2/xml/ dom /usr/bin/install -c -m 644 ./Lib/xml/parsers/__init__.py /usr/local/lib/python2.2/x ml/parsers /usr/bin/install -c -m 644 ./Lib/xml/parsers/expat.py /usr/local/lib/python2.2/xm l/parsers /usr/bin/install -c -m 644 ./Lib/xml/sax/__init__.py /usr/local/lib/python2.2/xml/s ax /usr/bin/install -c -m 644 ./Lib/xml/sax/_exceptions.py /usr/local/lib/python2.2/x ml/sax /usr/bin/install -c -m 644 ./Lib/xml/sax/expatreader.py /usr/local/lib/python2.2/ xml/sax /usr/bin/install -c -m 644 ./Lib/xml/sax/handler.py /usr/local/lib/python2.2/xml/s ax /usr/bin/install -c -m 644 ./Lib/xml/sax/saxutils.py /usr/local/lib/python2.2/xml/s ax /usr/bin/install -c -m 644 ./Lib/xml/sax/xmlreader.py /usr/local/lib/python2.2/xm l/sax /usr/bin/install -c -m 644 ./Lib/curses/__init__.py /usr/local/lib/python2.2/curses /usr/bin/install -c -m 644 ./Lib/curses/ascii.py /usr/local/lib/python2.2/curses /usr/bin/install -c -m 644 ./Lib/curses/has_key.py /usr/local/lib/python2.2/curse s /usr/bin/install -c -m 644 ./Lib/curses/panel.py /usr/local/lib/python2.2/curses /usr/bin/install -c -m 644 ./Lib/curses/textpad.py /usr/local/lib/python2.2/curse s /usr/bin/install -c -m 644 ./Lib/curses/wrapper.py /usr/local/lib/python2.2/curse s /usr/bin/install -c -m 644 ./Lib/plat- linux2/CDROM.py /usr/local/lib/python2.2/plat-linux2 /usr/bin/install -c -m 644 ./Lib/plat- linux2/DLFCN.py /usr/local/lib/python2.2/plat-linux2 /usr/bin/install -c -m 644 ./Lib/plat- linux2/IN.py /usr/local/lib/python2.2/plat-linux2 /usr/bin/install -c -m 644 ./Lib/plat- linux2/TYPES.py /usr/local/lib/python2.2/plat-linux2 /usr/bin/install -c ./Lib/plat- linux2/regen /usr/local/lib/python2.2/plat-linux2 /usr/bin/install -c -m 644 ./LICENSE /usr/local/lib/python2.2/LICENSE.txt PYTHONPATH=/usr/local/lib/python2.2 \ ./python - tt /usr/local/lib/python2.2/compileall.py -x badsyntax \ /usr/local/lib/python2.2 Listing /usr/local/lib/python2.2 ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... (etc.) |
|||
msg13249 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-11-16 09:52 | |
Logged In: YES user_id=21627 As a procedural comment: What is the source package that you use (precise URL please)? Can you please provide the output of ls -l /usr/local/lib/python2.2 |
|||
msg13250 - (view) | Author: Mel (meldh) | Date: 2002-11-16 10:36 | |
Logged In: YES user_id=649744 I downloaded it from http://www.python.org/ftp/python/2.2.2/Python-2.2.2.tgz (the most obvious link off www.python.org). Directory listing attached (I hope) |
|||
msg13251 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-11-16 14:35 | |
Logged In: YES user_id=21627 I still have no clue what is going on here. Can you please apply the attached compileall.diff, rerun installation, and attach the resulting log file (or a significant portion thereof)? |
|||
msg13252 - (view) | Author: Mel (meldh) | Date: 2002-11-16 15:59 | |
Logged In: YES user_id=649744 That's OK, me neither. ;) I've patched compileall.py and reran 'make install'. The log file doesn't tell me a whole lot more but I confess I'm no Python expert (I need to get it installed for a different app which requires it). Log file attached. Be warned, uncompressed it is about 6Mb. |
|||
msg13253 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-11-16 16:31 | |
Logged In: YES user_id=21627 I'm now convinced that there must be cyclic symbolic link somewhere. Please report the output of find /usr/local/lib/python2.2 -type l -print |
|||
msg13254 - (view) | Author: Mel (meldh) | Date: 2002-11-17 19:16 | |
Logged In: YES user_id=649744 Zero output from that, I'm afraid. This is very weird. |
|||
msg13255 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-11-17 21:00 | |
Logged In: YES user_id=21627 Ok, more tests: Can you please perform a file system check on that file system? Normally, I would also ask for strace output, but I suppose your strace won't decode getdents64. |
|||
msg13256 - (view) | Author: Mel (meldh) | Date: 2002-11-17 22:38 | |
Logged In: YES user_id=649744 I can't do an fsck on that filesystem until I'm in front of the console tomorrow - no reason to suspect problems, though. I've attached a gzipped version of the output of 'strace make install'. |
|||
msg13257 - (view) | Author: Mel (meldh) | Date: 2002-11-18 11:43 | |
Logged In: YES user_id=649744 fsck reports /usr('s filesystem) is clean. |
|||
msg13258 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-11-18 12:04 | |
Logged In: YES user_id=21627 Ok, I give up. Unless somebody else has any idea, I will close this as unreproducable. |
|||
msg13259 - (view) | Author: Mel (meldh) | Date: 2002-11-18 12:07 | |
Logged In: YES user_id=649744 I'm just trying to install from the same .tar.gz file I originally downloaded on a machine with a very similar setup (not, sadly, identical). Let's see if it does the same thing. |
|||
msg13260 - (view) | Author: Mel (meldh) | Date: 2002-11-18 12:20 | |
Logged In: YES user_id=649744 ... which, bizarrely, works. The main difference seems to be that it gets as far as the line which reads: Listing /usr/local/lib/python2.2 ... and then it _doesn't_ go on to produce a(n infinite number of) lines saying: Listing /usr/local/lib/python2.2/ ... (with the extra / appended to the name of the directory listing). What's actually _supposed_ to happen with that line? It passes a directory listing back to the shell? (Listings work OK on the problem machine as far as I can tell.) OK, next step. Delete build directory, delete install directory, untar the tarball again and start over from scratch. |
|||
msg13261 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-11-18 12:25 | |
Logged In: YES user_id=21627 I'm not surprised it works; this behaviour is expected. Python recursively traverses all directories under /usr/local/lib/python2.2, and produces bytecode files for each .py file. For some reason, it concludes that /usr/local/lib/python2.2/ is a subdirectory of /usr/local/lib/python2.2 on your first machine, which is non-sense. |
|||
msg13262 - (view) | Author: Mel (meldh) | Date: 2002-11-18 12:28 | |
Logged In: YES user_id=649744 And still fails to work on the first machine. One thing I did notice was that on the second machine (the one on which the install works), there were a _lot_ more tests done with 'make test'. 240 or so, versus 6 on the not- working machine. |
|||
msg13263 - (view) | Author: Mel (meldh) | Date: 2002-11-18 12:36 | |
Logged In: YES user_id=649744 OK, I've started reinstalling from scratch on both machines, and I'm logging the outputs from ./configure, make, make test, make install. _Something's_ got to be different... |
|||
msg13264 - (view) | Author: Neal Norwitz (nnorwitz) * | Date: 2002-11-18 13:29 | |
Logged In: YES user_id=33168 Mel, is any path in /usr/local/lib/python2.2 a symlink, meaning: /usr, /usr/local, or /usr/local/lib ? |
|||
msg13265 - (view) | Author: Mel (meldh) | Date: 2002-11-18 13:35 | |
Logged In: YES user_id=649744 Output of ./configure is identical on both machines. Output of make is slightly different (much of the difference is because one machine is 586 arch. and the other 686) Attached tgz file includes all three logs for each machine and a diff file for each set. Logs prefixed with 'sun-' are from the machine where the install works; logs prefixed with 'van-' are from the machine where the install fails. |
|||
msg13266 - (view) | Author: Mel (meldh) | Date: 2002-11-18 13:51 | |
Logged In: YES user_id=649744 Nope, all components of /usr/local/lib appear to be normal, healthy directories; no symlinks in there at all. The actual built copies of python awaiting install are slightly different sizes on the two machines, which may or may not be significant (2177764 on working machine, 2177796 on not-working machine) |
|||
msg13267 - (view) | Author: Jack Jansen (jackjansen) * | Date: 2002-11-18 14:20 | |
Logged In: YES user_id=45365 If os.listdir("/usr/local/lib/python2.2") would return an empty string as the first item in it's output (it shouldn't, of course) I could imagine this happening. Could you do the following: % PYTHONPATH=/usr/local/lib/python2.2 ./python >>> import os >>> os.listdir("/usr/local/lib/python2.2") and show us the results? |
|||
msg13268 - (view) | Author: Mel (meldh) | Date: 2002-11-18 14:42 | |
Logged In: YES user_id=649744 Erk. On the working install, it returns ['filename','filename',....,'filename'] (in other words, it looks wholly normal) On the not-working install, it returns ['','','',...,''] (if the exact number of empty pairs of quotes is critical, I can count them) I checked whether it would list other directories and no, it does the same thing on those also; produces a bunch of empty pairs of quotes (one per file, from the looks of it) |
|||
msg13269 - (view) | Author: Neal Norwitz (nnorwitz) * | Date: 2002-11-18 15:13 | |
Logged In: YES user_id=33168 Are you able to use a debugger and break in posix_listdir() to see what's going on? |
|||
msg13270 - (view) | Author: Mel (meldh) | Date: 2002-11-18 15:35 | |
Logged In: YES user_id=649744 I have gdb installed but doing: gdb python break posix_listdir run import os os.listdir("/some/directory") doesn't actually cause a break; it does the same as last time (produces a list of empty pairs of quotes) and then ends normally when I quit out of it. It also doesn't break there in the working version. |
|||
msg13271 - (view) | Author: Mel (meldh) | Date: 2002-11-18 15:36 | |
Logged In: YES user_id=649744 I should add that it does seem to set up the breakpoint correctly; it reports that it's setting up breakpoint 1 in ./Modules/posixmodule.c, line 1157 (on both machines) (Appreciate all your work on this, folks.) |
|||
msg13272 - (view) | Author: Neal Norwitz (nnorwitz) * | Date: 2002-11-18 16:08 | |
Logged In: YES user_id=33168 I think this is b/c posix is shared. This is the process you need to do (hopefully this is correct, it's from memory): gdb python run >>> import os >>> # press Ctrl-C to get back to gdb (gdb) br posix_listdir (gdb) continue >>> os.listdir("/usr/local/lib/python2.2") |
|||
msg13273 - (view) | Author: Mel (meldh) | Date: 2002-11-18 16:25 | |
Logged In: YES user_id=649744 Sorry, still no joy (same output as before; no break) |
|||
msg13274 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-11-18 23:12 | |
Logged In: YES user_id=21627 Can you please report C library version and kernel version of your system? It may that large file system support is somehow broken; please try the following build procedure: - configure - edit pyconfig.h, remove the line HAVE_LARGEFILE_SUPPORT _LARGEFILE_SOURCE _FILE_OFFSET_BITS - make, make install Still, getting a meaningful debug session would be useful. |
|||
msg13275 - (view) | Author: Mel (meldh) | Date: 2002-11-18 23:24 | |
Logged In: YES user_id=649744 Kernel version 2.2.18pre21 (as noted in initial report). I've attached the output from '/sbin/ldconfig -p'. I'll try the suggested tweak in a moment, though if 'large file system' means 'over 2Gb' as I think it may do, it should be a non-issue; none of the partitions on the box are over 2Gb. |
|||
msg13276 - (view) | Author: Mel (meldh) | Date: 2002-11-18 23:32 | |
Logged In: YES user_id=649744 It's looking good; I'm running 'make test' at the moment and it's doing a whole bunch of tests rather than the paltry six it was coming up with before (because it wasn't finding the rest because they were in subdirectories, maybe?) |
|||
msg13277 - (view) | Author: Mel (meldh) | Date: 2002-11-18 23:40 | |
Logged In: YES user_id=649744 OK, some tests failed. I'll look at that more closely tomorrow. |
|||
msg13278 - (view) | Author: Jack Jansen (jackjansen) * | Date: 2002-11-19 09:48 | |
Logged In: YES user_id=45365 WRT the debugger not working: are you sure you are actually using the posix module you think you're using? If you're somehow picking up a module that is meant for a different Python I could imagine random failures (like listdir returning empty strings). Could you run the listdir test with "python -v", and check that you are actually importing the posixmodule it should be importing? |
|||
msg13279 - (view) | Author: Mel (meldh) | Date: 2002-11-19 11:02 | |
Logged In: YES user_id=649744 Okay. The current situation after fixing pyconfig.h in the manner suggested by loewis is: - os.listdir now does what it ought to (i.e. lists the directory instead of lots of sets of empty quotes) - make appears to work OK - make test fails in some places, which I am now re-running to log - haven't tried make install yet (and would prefer to get make test running cleanly first in any case) Jack: this box didn't actually have a previous Python install as far as I am aware. (certainly 'which python' doesn't give me anything and I don't remember installing it when I set the box up last month). Only Python files, then, are in the build directory... |
|||
msg13280 - (view) | Author: Mel (meldh) | Date: 2002-11-19 11:20 | |
Logged In: YES user_id=649744 Attached is log of 'make install'. Could someone take a look and tell me which (if any) of these errors I should be concerned about? (the ones relating to _socket look likely candidates) |
|||
msg13281 - (view) | Author: Neal Norwitz (nnorwitz) * | Date: 2002-11-19 13:44 | |
Logged In: YES user_id=33168 It appears all the failures are due to the socket failure. I don't know why socket failed to import, you can try importing it manually and see the error message you get. If you changed pyconfig.h manually, you may need to remove your entire build/ directory. The dependancies in Modules/ don't always rebuild everything they need to, I think. Mel, I think what Jack wanted, was for you to do this: ./python -v ./Lib/test/regrtest.py test_os.py This will show what is being imported. Mine shows this: [neal@epoch src]$ ./python -v ./Lib/test/regrtest.py test_os.py # /home/neal/build/python/dist/src/Lib/site.pyc matches /home/neal/build/python/dist/src/Lib/site.py import site # precompiled from /home/neal/build/python/dist/src/Lib/site.pyc # /home/neal/build/python/dist/src/Lib/os.pyc matches /home/neal/build/python/dist/src/Lib/os.py import os # precompiled from /home/neal/build/python/dist/src/Lib/os.pyc import posix # builtin So we see posix being imported. Jack seems to think (I've had the same thought) that when you run os.listdir() that is not calling the C posix_listdir() as it seems it should. You could do what I suggested before in the debugger, but break in PyEval_EvalCode(), fast_cfunction() and fast_function() and step through to find what's happening. For me, PyEval_EvalCode is where I break when running os.listdir(). I'm not sure where I got this from, but you can use this macro in gdb to print the python stack too. It's quite handy: define ppystack while $pc < Py_Main || $pc > Py_GetArgcArgv if $pc > eval_frame && $pc < PyEval_EvalCodeEx set $__fn = PyString_AsString(co->co_filename) set $__n = PyString_AsString(co->co_name) printf "%s (%d): %s\n", $__fn, f->f_lineno, $__n end up-silently 1 end select-frame 0 end I'm not sure if any of this will help, but it's more things to try to figure out the real problem. |
|||
msg13282 - (view) | Author: Mel (meldh) | Date: 2002-11-19 14:09 | |
Logged In: YES user_id=649744 OK, let me rebuild without the pyconfig.h changes (so that I get back to a version in which os.listdir doesn't work) and see if I can get gdb to do something useful; I'll set the breakpoints where you suggested and see what happens. More soon. |
|||
msg13283 - (view) | Author: Mel (meldh) | Date: 2002-11-19 14:17 | |
Logged In: YES user_id=649744 Posix is being imported as a builtin, same as your log - I've attached the output of test_os.py below. Now I'll have a crack at the debugger. |
|||
msg13284 - (view) | Author: Mel (meldh) | Date: 2002-11-19 14:45 | |
Logged In: YES user_id=649744 Running the debugger on the version built without the pyconfig.h changes (which does indeed still mean that os.listdir is broken) does break first in PyEval_EvalCode. Stepping through... hm. Attached gdb.log doesn't tell me a whole lot, but I'm hoping it'll make more sense to the rest of you out there. |
|||
msg13285 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-11-19 16:57 | |
Logged In: YES user_id=21627 In the line that reads 79 return (*meth)(self, arg); you should be stepping into the function that will is called, i.e. posix_listdir. If gdb does not step into that function, can you please find out what the value of meth is, and how it compares to the address of posix_listdir? |
|||
msg13286 - (view) | Author: Mel (meldh) | Date: 2002-11-19 17:23 | |
Logged In: YES user_id=649744 Looks to me like it's trying to do the right thing... [lots of stepping elided] 79 return (*meth)(self, arg); (gdb) print meth $1 = 0x809a5ec <posix_listdir> (gdb) $2 = 0x809a5ec <posix_listdir> (gdb) step ['', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', ''] >>> quit If you want a copy of the full log with all the steps in, let me know (though it'll look a lot like the earlier one) |
|||
msg13287 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-11-19 18:14 | |
Logged In: YES user_id=21627 What we need is a step *through* posix_listdir. If step won't enter the function, please try stepi for a couple of instructions (10 or so), then do "info source", and "bt". |
|||
msg13288 - (view) | Author: Mel (meldh) | Date: 2002-11-19 18:28 | |
Logged In: YES user_id=649744 Log of stepthrough attached. |
|||
msg13289 - (view) | Author: Neal Norwitz (nnorwitz) * | Date: 2002-11-19 18:41 | |
Logged In: YES user_id=33168 Getting closer, we need a bit more though. Where the list is created is in the loop 9+ lines down from PyArg_ParseTuple() at line 1156. My guess is that the string is coverted to the empty string on line 1170 each time through the loop. Can you print *ep? I'm guessing that ep->d_namlen == 0 but there is a string in ep->d_name. Is this what's happening? |
|||
msg13290 - (view) | Author: Neal Norwitz (nnorwitz) * | Date: 2002-11-19 18:43 | |
Logged In: YES user_id=33168 It would be good to step into PyString_FromStringAndSize() to see the parameter values for the string and size too. |
|||
msg13291 - (view) | Author: Mel (meldh) | Date: 2002-11-19 19:01 | |
Logged In: YES user_id=649744 Okay, done (I think). Gzipped output attached. Warning: long, dull... |
|||
msg13292 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-11-19 22:44 | |
Logged In: YES user_id=21627 It looks like posixmodule is miscompiled. Can you please compile the attached l.c both with and without -D_HAVE_LARGEFILE_SUPPORT=1 -D_FILE_OFFSET_BITS=64 It should print out the directory contents of the current directory in both cases. If it doesn't, please attach the preprocessor output for both compilations (obtained with --save-temps, as l.i). Also, your ldconfig output does not provide the glibc version, please use "dpkg -l libc6" to report the precise version. |
|||
msg13293 - (view) | Author: Mel (meldh) | Date: 2002-11-19 23:22 | |
Logged In: YES user_id=649744 dpkg -l libc6 reckons that the library is version 2.2.5-6. Compiling now. |
|||
msg13294 - (view) | Author: Mel (meldh) | Date: 2002-11-19 23:32 | |
Logged In: YES user_id=649744 Compiling without the defines produces a version which correctly lists the directory. Compiling with the defines produces a version which lists a set of empty quotes. |
|||
msg13295 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-11-20 08:25 | |
Logged In: YES user_id=21627 I would now propose to close this bug as 3rdparty: somehow, large file system (LFS) support is not working on your system, in a very subtle way. Since we cannot pin the problem, I can only recommend to manually disable LFS when configuring Python on this system, by editing pyconfig.h. It looks like the fault is not in the C library. If you want to investigate further, I recommend the following tests: - copy the binary that lists a set of empty quotes onto the other machine. See if it works there. - if it does work there, link the binary statically, and try again, on both systems. |
|||
msg13296 - (view) | Author: Mel (meldh) | Date: 2002-11-20 09:06 | |
Logged In: YES user_id=649744 I think that seems reasonable. By editing pyconfig.h, I can at least get a version which works (well, aside from those weirdnesses with not importing socket properly, but those look to be unrelated). Thanks again to all involved for your help. Very odd one... |
|||
msg13297 - (view) | Author: Steve Traugott (stevegt) | Date: 2003-01-10 05:36 | |
Logged In: YES user_id=17621 FYI I ran into the same problem on a RedHat 7.2-ish machine. The pyconfig.h workaround described earlier (deleting the three #defines for large file support) works. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:05:54 | admin | set | github: 37479 |
2002-11-15 18:09:29 | meldh | create |