Solaris 2.7 make chokes.

[sharadinfozen]

BPO	510868
Nosy	@loewis
Files	makeconfig.log: Config.log & Make.log all shmucked together. gdbpyth: gdb python output gdbout: a better gdb python output gdbout2: Backtrace on gdb python output backtrace.feb4: backtrace log for failed make Feb 4.

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2002-03-28.16:43:42.000>
created_at = <Date 2002-01-30.19:33:22.000>
labels = ['expert-installation']
title = 'Solaris 2.7 make chokes.'
updated_at = <Date 2002-03-28.16:43:42.000>
user = 'https://bugs.python.org/sharadinfozen'

bugs.python.org fields:

activity = <Date 2002-03-28.16:43:42.000>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Installation']
creation = <Date 2002-01-30.19:33:22.000>
creator = 'sharadinfozen'
dependencies = []
files = ['315', '316', '317', '318', '319']
hgrepos = []
issue_num = 510868
keywords = []
message_count = 12.0
messages = ['9044', '9045', '9046', '9047', '9048', '9049', '9050', '9051', '9052', '9053', '9054', '9055']
nosy_count = 2.0
nosy_names = ['loewis', 'sharadinfozen']
pr_nums = []
priority = 'normal'
resolution = 'works for me'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue510868'
versions = ['Python 2.2']

[sharadinfozen]

I'm building python2.2 on a Solaris2.7 box, an Ultra-
10.

I get a segmentation fault error at 'xreadlines' when
I try the make.

I am not sure why.

Logs of the configuration script & make are attached.
(in one concatenated file, I could not tell how to
upload more than one file).

Any help will be greatly appreciated.

thanks!
-sharad.

[loewis]

Logged In: YES
user_id=21627

Can you attach to Python with gdb and see why it crashes?

[sharadinfozen]

Logged In: YES
user_id=443851

I did try gdb on the python binary, but got nothing
interesting (you can see in the file gdbpyth).

thanks,
-sharad.

[loewis]

Logged In: YES
user_id=21627

It would be good if you could analyse this with gdb further.
I recommend to obtain a more recent copy of gdb (e.g. gdb
5.0), in particular one compiled for your system (the one
you have is compiled for Solaris 2.4). You can get get
binaries from sunfreeware.com (although they don't have gdb
5 for Solaris 7; you might want to try the 4.18 that they do
have).

The important thing is that you need to run the setup.py
under gdb. To do this, please invoke the setup.py line
manually. I.e. if the makefile invoke

ENV1=val1 ENV2=val2 python-command python-options arguments

you will need to perform the following commands

ENV1=val1
ENV2=val2
export ENV1 ENV2
gdb python-command
run python-options arguments

As a side point, what is the exact gcc version that you are
usingq (gcc -v)? If that also is not a gcc for Solaris 7, I
recommend to re-install the compiler, or use the system
compiler.

[sharadinfozen]

Logged In: YES
user_id=443851

Thanks for the gdb tip, I've switched to the solaris7 pkg
for gdb. The version info for gcc does not explicitly list
what flavor of Solaris it's built for, but the version
number is 3.0.3, and it reads it's specs
from /usr/local/lib/gcc-lib/sparc-sun-
solaris2.7/3.0.3/specs, which leads me to believe that it's
built for solaris7.

Anywho, after some freaking around with env var's & gdb, I
got the following output (see gdbout). It leads me to
believe that the problem is in /usr/lib/libc.so.1, but I'm
not sure how to replace/update this lib, or even if it is
indeed the source of my python misery.

Any input or guidance would be appreciated.

thanks,
-sharad.

[loewis]

Logged In: YES
user_id=21627

Ok, gcc 3.0.3 itself could be a source of problems, but I
won't accuse that compiler prematurely (you might want to
try 2.95.x, though, if you have that readily available).

As for the gdb analysis: that it crashes is strlen is not
the problem; strlen is the innocent C library function that
computes the length of the string. Please invoke the command
"bt" when it crashes; that should tell you the backtrace
(i.e. where strlen is called from) - please report that.

If you want to investigate further: "up" brings you up a
stack-level, and "p varname" prints a variable.

This approach to debugging may take many more rounds, so I'd
understand if you are ready to give up (sunfreeware has
2.1.1 binaries). It's just that it builds fine for me (on
Solaris 8, using gcc 2.95.2), so I have no clue as to what
the problem might be. Did you pass any options to ./configure?

[sharadinfozen]

Logged In: YES
user_id=443851

I've done a full backtrace on it (see gdbout2), but I
really don't know how to interpret the results. From what
I can tell, the problem lies in this area:
#1 0x20f00 in PyString_FromString (
str=0x7e1138 <Address 0x7e1138 out of bounds>)
at Objects/stringobject.c:112
#2 0xad7dc in PyDict_SetItemString (v=0x7e1138,
key=0x7e1138 <Address 0x7e1138 out of bounds>,
item=0x17d350)
at Objects/dictobject.c:1879

Unfotunately, I can't tell what's going wrong in these
source files, and when I tried 'p str' on the var
referenced in line #1, I get:
$1 = 0x7e1138 <Address 0x7e1138 out of bounds>
which does not explain much to me.

I have tried the package at SunFreeWare's site, but my
developer needs the 'HTTPSConnection' from 'httplib', which
apparently is _not_ built into the sunfreeware package.

So, any input, again, would be greatly appreciated.

I realise you must be a busy guy, thanks for all of your
help & patience!
-sharad.

[loewis]

Logged In: YES
user_id=21627

That looks very much like a miscompilation. Notice that
initreadline is supposed to pass a first string of
"readline" to InitModule4; in the gdb backtrace, we see an
empty string. Likewise, the invalid address comes from the
methods argument to InitModule4, fetching ml_name. These are
all static strings, compiled into an array (namely,
readline.c:readline_methods).

So I really recommend to downgrade the compiler (or use the
Sun system compiler if you have it); if you are interested
in a work-around, here are two options:

• build readline statically into the Python interpreter. Do
  so by uncommenting the readline line in Modules/Setup
  (adding libraries as necessary)
• do not build the readline module at all; do so by adding
  'readline' into setup.py:disabled_module_list.

[sharadinfozen]

Logged In: YES
user_id=443851

I tried downgrading gcc to 2.95.3, however, it still craps
out at the same place, and according to backtrace, it is
still quitting in the same place.

I've attached the logs.

We've successfully built python on another box, keeping the
project that was in jeopardy moving forward, however, I
would still very much like to find out how to install
python correctly on this problem box.

thanks,
-sharad.

[loewis]

Logged In: YES
user_id=21627

Can you offer an account on this machine? I'd like to
investigate it "life".

[sharadinfozen]

Logged In: YES
user_id=443851

Thanks for the followup, but due to the nature of the
project this box is involved in, and my company's policies,
I would get in serious poo-poo if I let you in.

I think we will just have to concede on this, and move on.

thanks again.
-sharad.

[loewis]

Logged In: YES
user_id=21627

Ok, closing it as not-reproducable.