Re: remote XOpenDisplay in Solaris (SunOS 5.6)

Re: remote XOpenDisplay in Solaris (SunOS 5.6)

[Jerry Miller]

Here's a dump of the first few values in big-endian
shortword format (patterned after od -x).  Does
anyone know enough assembler for the UltraSparc 5
(68XXX???) to be able to tell me where the address
starts (and whether it is an actual address or a further
indirection)?

0300 099c 30bf fd98 0100 0000 0100 0000
001f cb28 0000 0040 0000 0000 001f 802c

A simple test program, which does nothing but call
the dump function, instead yields:

0300 0084 30bf ffde 0100 0000 0100 0000
0002 0a88 0000 0000 0000 0000 0002 09b4

(Where's a disassembler when I need one?!?!)

----- Original Message -----
From: Jerry Miller <gmiller@cs.sunysb.edu>
To: Jerry Miller <gmiller@cs.sunysb.edu>; David Korn <dkorn@pixelpower.com>;
<help-gcc@gnu.org>
Sent: Tuesday, February 27, 2001 2:06 PM
Subject: Re: remote XOpenDisplay in Solaris (SunOS 5.6)


> Never mind never minding - the Solaris version
> doesn't recognize the -Map option!
>

Re: remote XOpenDisplay in Solaris (SunOS 5.6)

[Jerry Miller]

Well, I guess that's why it's good form to prefix function names
with an abbreviation based on the module- or application-name.

In contrast, I was able to get some degree of control (not much)
over Motif's nonsensical stacking order by #define-ing XtManageChild
and XtUnmanageChild to have my own function calls intercept them
before handing them off to these undisciplined (and downright
hostile and obstinate) functions.

----- Original Message -----
From: David Korn <dkorn@pixelpower.com>
To: 'Jerry Miller' <gmiller@cs.sunysb.edu>; <help-gcc@gnu.org>
Sent: Wednesday, February 28, 2001 10:31 AM
Subject: RE: remote XOpenDisplay in Solaris (SunOS 5.6)


> >-----Original Message-----
> >From: Jerry Miller [ mailto:gmiller@cs.sunysb.edu ]
> >Sent: 28 February 2001 14:07
>
> >That did it!  Thank you!
>
>   Hooray!!
>
> >I hadn't experimented enough with gdb to realize that the
> >"up" command was virtually equivalent to the PL/I tracebacks
> >I used to rely on.  When I discovered that my function
> >putmsg was being called by a shared-library routine, I did a
> >"man putmsg," and sure enough, there was a conflict there!
>
>   There's also the 'bt' command, which lists the entire stack all the way
> back to the program entry point for you.
>
> >Making it a static local function and renaming it for good
> >measure has solved this mysterious problem.
>
>   Argh!  Whoever invented the notion that DSOs could have unresolved
> symbols in them is a maniac who should be shot through the ears.  Despite
> the fact that the price of disk storage has fallen through the floor, it
> is seemingly so important to save a few meg here and there that we have
> arrived in a situation where nobody except the linker can even begin to
> guess what function is actually going to be called by a function call.  It
> might perhaps be not quite so bad if unresolved syms in DSOs could only
> be resolved by syms from other libs, but the thought that a DSO can
contain
> an unresolved reference to a system function that ends up getting linked
to
> your own application is just annoying.  I'm used to systems where you can
> write a function called printf and that's what you'll get when your app.
> calls printf, but I'm just not used to the notion that the C runtime
library
> might suddenly start calling your function instead of it's own.
>
>        DaveK
> --
>  All your base are belong to us!
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
> www.mimesweeper.com
> **********************************************************************
>

RE: remote XOpenDisplay in Solaris (SunOS 5.6)

[David Korn]

>-----Original Message-----
>From: Jerry Miller [ mailto:gmiller@cs.sunysb.edu ]
>Sent: 28 February 2001 14:07

>That did it!  Thank you!

  Hooray!! 

>I hadn't experimented enough with gdb to realize that the
>"up" command was virtually equivalent to the PL/I tracebacks
>I used to rely on.  When I discovered that my function
>putmsg was being called by a shared-library routine, I did a
>"man putmsg," and sure enough, there was a conflict there!

  There's also the 'bt' command, which lists the entire stack all the way
back to the program entry point for you.

>Making it a static local function and renaming it for good
>measure has solved this mysterious problem.

  Argh!  Whoever invented the notion that DSOs could have unresolved
symbols in them is a maniac who should be shot through the ears.  Despite
the fact that the price of disk storage has fallen through the floor, it
is seemingly so important to save a few meg here and there that we have
arrived in a situation where nobody except the linker can even begin to
guess what function is actually going to be called by a function call.  It
might perhaps be not quite so bad if unresolved syms in DSOs could only
be resolved by syms from other libs, but the thought that a DSO can contain
an unresolved reference to a system function that ends up getting linked to
your own application is just annoying.  I'm used to systems where you can
write a function called printf and that's what you'll get when your app.
calls printf, but I'm just not used to the notion that the C runtime library
might suddenly start calling your function instead of it's own.

       DaveK
-- 
 All your base are belong to us!


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: remote XOpenDisplay in Solaris (SunOS 5.6)

[Jerry Miller]

That did it!  Thank you!

I hadn't experimented enough with gdb to realize that the
"up" command was virtually equivalent to the PL/I tracebacks
I used to rely on.  When I discovered that my function
putmsg was being called by a shared-library routine, I did a
"man putmsg," and sure enough, there was a conflict there!

Making it a static local function and renaming it for good
measure has solved this mysterious problem.

----- Original Message -----
From: David Korn <dkorn@pixelpower.com>
To: 'Jerry Miller' <gmiller@cs.sunysb.edu>; <help-gcc@gnu.org>
Sent: Wednesday, February 28, 2001 5:29 AM
Subject: RE: remote XOpenDisplay in Solaris (SunOS 5.6)


> >-----Original Message-----
> >From: Jerry Miller [ mailto:gmiller@cs.sunysb.edu ]
> >Sent: 27 February 2001 19:17
>
> >Here's a dump of the first few values in big-endian
> >shortword format (patterned after od -x).  Does
> >anyone know enough assembler for the UltraSparc 5
> >(68XXX???) to be able to tell me where the address
> >starts (and whether it is an actual address or a further
> >indirection)?
> >
> >0300 099c 30bf fd98 0100 0000 0100 0000
> >001f cb28 0000 0040 0000 0000 001f 802c
> >
> >A simple test program, which does nothing but call
> >the dump function, instead yields:
> >
> >0300 0084 30bf ffde 0100 0000 0100 0000
> >0002 0a88 0000 0000 0000 0000 0002 09b4
>
>   Is this the actual linked code from memory, or are you dumping the
> object file here?  All those zeroes don't look right to me, so if this
> is what's in memory, it looks like it hasn't been linked correctly.
>
> >(Where's a disassembler when I need one?!?!)
>
>   Right, let me think about this.  We know that the first few instructions
> are the function prologue, so I'd reckon that those negative numbers
> $fd98 and $ffde are the stack frame adjustments, so that would mean that
> $30bf $xxxx is link #xxxx,a6.  $0a88 is one I vaguely recognize as well,
> I think that's a load to a register....  All those zeroes just can't be
> right though.
>
>   I think your best bet is to run your program under gdb.  That will trap
> on the segv and you can have a look at the stack frame and see which
> functions have been called by which other functions in which order.
>
>        DaveK
> --
>  All your base are belong to us!
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
> www.mimesweeper.com
> **********************************************************************
>

RE: remote XOpenDisplay in Solaris (SunOS 5.6)

[David Korn]

>-----Original Message-----
>From: Jerry Miller [ mailto:gmiller@cs.sunysb.edu ]
>Sent: 27 February 2001 19:17

>Here's a dump of the first few values in big-endian
>shortword format (patterned after od -x).  Does
>anyone know enough assembler for the UltraSparc 5
>(68XXX???) to be able to tell me where the address
>starts (and whether it is an actual address or a further
>indirection)?
>
>0300 099c 30bf fd98 0100 0000 0100 0000
>001f cb28 0000 0040 0000 0000 001f 802c
>
>A simple test program, which does nothing but call
>the dump function, instead yields:
>
>0300 0084 30bf ffde 0100 0000 0100 0000
>0002 0a88 0000 0000 0000 0000 0002 09b4

  Is this the actual linked code from memory, or are you dumping the 
object file here?  All those zeroes don't look right to me, so if this
is what's in memory, it looks like it hasn't been linked correctly.

>(Where's a disassembler when I need one?!?!)

  Right, let me think about this.  We know that the first few instructions
are the function prologue, so I'd reckon that those negative numbers
$fd98 and $ffde are the stack frame adjustments, so that would mean that
$30bf $xxxx is link #xxxx,a6.  $0a88 is one I vaguely recognize as well,
I think that's a load to a register....  All those zeroes just can't be
right though.

  I think your best bet is to run your program under gdb.  That will trap
on the segv and you can have a look at the stack frame and see which 
functions have been called by which other functions in which order.

       DaveK
-- 
 All your base are belong to us!


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

RE: remote XOpenDisplay in Solaris (SunOS 5.6)

[David Korn]

>-----Original Message-----
>From: Jerry Miller [ mailto:gmiller@cs.sunysb.edu ]
>Sent: 27 February 2001 18:43


>I thought I had a clever idea for detection corruption in the
>XOpenDisplay function.  I would simply cast the function
>address to a char * and dump the contents.
>
>Of course, I then remembered my own development of
>a linker for the 6809 many years ago.  I simply reserved
>space for a JMP statement to be resolved by the linker.

    Hi Jerry,

  I'm not quite sure what you're getting at here; are you worried that
the actual program code itself is being overwritten perhaps by a stray 
pointer?  That's always a possibility but I thought Solaris had an MMU
and would mark the text pages of your application as read-only, so if
that was going to happen you'd get a SEGV.  I could be wrong of course,
particularly if it's an early 68xxx series.

  Anyway your technique (assuming it's not superfluous because of write
protection on the code) is sound; linkers are generally just as happy to
resolve the address in the operand field of a load instruction as they
are to resolve the address in the operand field of a jump instruction,
so it should work fine. Indeed, I use the same technique myself.  You can
simplify it a bit; rather than dumping the entire contents of the 
function to see what changes, just keep a checksum of the region in a 
static variable somewhere and see if it changes; then you'll have a lot
less debugging output to plough through visually.  If that technique
shows that the checksum does indeed change, that's the time to start
dumping the function out; and even then it might not be a terribly 
useful exercise.  Although it is conceivable that you might see a word
has been changed to a bit pattern that you can recognize as a specific
piece of data from some identifiable part of the program, it's more likely
to just be zeros or junk.  But at least it would tell you what's going
on.

>So it turns out that what I really need is a load map.
>I've been through the man pages for ld, but the only
>reference that looks relevant (but isn't) is -M.  Any
>suggestions?

  *Why* isn't the -M or -Map option relevant?  And from this and your
other mail on the subject, I'm starting to wonder: is your gcc set up
to use the GNU linker or the Solaris one?  Check the output from your
build when you add the -v flag to the gcc command line.

     DaveK
-- 
 All your base are belong to us!


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: remote XOpenDisplay in Solaris (SunOS 5.6)

[Jerry Miller]

Never mind never minding - the Solaris version
doesn't recognize the -Map option!

----- Original Message -----
From: Jerry Miller <gmiller@cs.sunysb.edu>
To: Jerry Miller <gmiller@cs.sunysb.edu>; David Korn <dkorn@pixelpower.com>;
<help-gcc@gnu.org>
Sent: Tuesday, February 27, 2001 2:03 PM
Subject: Re: remote XOpenDisplay in Solaris (SunOS 5.6)


> Never mind - I just looked at the man on Interix and found the -Map
> option.  Our Solaris implementation uses gnu software but retains the
> Solaris man pages!
>
> ----- Original Message -----
> From: Jerry Miller <gmiller@cs.sunysb.edu>
> To: David Korn <dkorn@pixelpower.com>; <help-gcc@gnu.org>
> Sent: Tuesday, February 27, 2001 1:43 PM
> Subject: Re: remote XOpenDisplay in Solaris (SunOS 5.6)
>
>
> > I thought I had a clever idea for detection corruption in the
> > XOpenDisplay function.  I would simply cast the function
> > address to a char * and dump the contents.
> >
> > Of course, I then remembered my own development of
> > a linker for the 6809 many years ago.  I simply reserved
> > space for a JMP statement to be resolved by the linker.
> >
> > So it turns out that what I really need is a load map.
> > I've been through the man pages for ld, but the only
> > reference that looks relevant (but isn't) is -M.  Any
> > suggestions?
> >
> > ----- Original Message -----
> > From: Jerry Miller <gmiller@cs.sunysb.edu>
> > To: David Korn <dkorn@pixelpower.com>; <help-gcc@gnu.org>
> > Sent: Friday, February 23, 2001 1:37 PM
> > Subject: Re: remote XOpenDisplay in Solaris (SunOS 5.6)
> >
> >
> > >
> > > ----- Original Message -----
> > > From: David Korn <dkorn@pixelpower.com>
> > > To: 'Jerry Miller' <gmiller@cs.sunysb.edu>; <help-gcc@gnu.org>
> > > Sent: Friday, February 23, 2001 1:03 PM
> > > Subject: RE: remote XOpenDisplay in Solaris (SunOS 5.6)
> > >
> > >
> > > >   I believe you can probably use the 'ldd' utility to find out which
> > > shared
> > > > objects an executable needs.  If not, 'man ld.so' might point you in
> the
> > > > right direction.  As I said, though, I'm not expert with shared
> objects.
> > >
> > > Except for the order in which they are listed, every GUI executable
> > > I subjected to ldd (those that bomb opening a remote display and
> > > those that don't) produced the same list:
> > >
> > >         libXm.so.3 =>    /usr/lib/libXm.so.3
> > >         libXt.so.4 =>    /usr/openwin/lib/libXt.so.4
> > >         libX11.so.4 =>   /usr/openwin/lib/libX11.so.4
> > >         libm.so.1 =>     /usr/lib/libm.so.1
> > >         libc.so.1 =>     /usr/lib/libc.so.1
> > >         libSM.so.6 =>    /usr/openwin/lib/libSM.so.6
> > >         libICE.so.6 =>   /usr/openwin/lib/libICE.so.6
> > >         libXext.so.0 =>  /usr/openwin/lib/libXext.so.0
> > >         libsocket.so.1 =>        /usr/lib/libsocket.so.1
> > >         libnsl.so.1 =>   /usr/lib/libnsl.so.1
> > >         libdl.so.1 =>    /usr/lib/libdl.so.1
> > >         libmp.so.2 =>    /usr/lib/libmp.so.2
> > >         /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
> > >
> > > Oh well - still no clues here!
> > >
> > >
> >
>

Re: remote XOpenDisplay in Solaris (SunOS 5.6)

[Jerry Miller]

Never mind - I just looked at the man on Interix and found the -Map
option.  Our Solaris implementation uses gnu software but retains the
Solaris man pages!

----- Original Message -----
From: Jerry Miller <gmiller@cs.sunysb.edu>
To: David Korn <dkorn@pixelpower.com>; <help-gcc@gnu.org>
Sent: Tuesday, February 27, 2001 1:43 PM
Subject: Re: remote XOpenDisplay in Solaris (SunOS 5.6)


> I thought I had a clever idea for detection corruption in the
> XOpenDisplay function.  I would simply cast the function
> address to a char * and dump the contents.
>
> Of course, I then remembered my own development of
> a linker for the 6809 many years ago.  I simply reserved
> space for a JMP statement to be resolved by the linker.
>
> So it turns out that what I really need is a load map.
> I've been through the man pages for ld, but the only
> reference that looks relevant (but isn't) is -M.  Any
> suggestions?
>
> ----- Original Message -----
> From: Jerry Miller <gmiller@cs.sunysb.edu>
> To: David Korn <dkorn@pixelpower.com>; <help-gcc@gnu.org>
> Sent: Friday, February 23, 2001 1:37 PM
> Subject: Re: remote XOpenDisplay in Solaris (SunOS 5.6)
>
>
> >
> > ----- Original Message -----
> > From: David Korn <dkorn@pixelpower.com>
> > To: 'Jerry Miller' <gmiller@cs.sunysb.edu>; <help-gcc@gnu.org>
> > Sent: Friday, February 23, 2001 1:03 PM
> > Subject: RE: remote XOpenDisplay in Solaris (SunOS 5.6)
> >
> >
> > >   I believe you can probably use the 'ldd' utility to find out which
> > shared
> > > objects an executable needs.  If not, 'man ld.so' might point you in
the
> > > right direction.  As I said, though, I'm not expert with shared
objects.
> >
> > Except for the order in which they are listed, every GUI executable
> > I subjected to ldd (those that bomb opening a remote display and
> > those that don't) produced the same list:
> >
> >         libXm.so.3 =>    /usr/lib/libXm.so.3
> >         libXt.so.4 =>    /usr/openwin/lib/libXt.so.4
> >         libX11.so.4 =>   /usr/openwin/lib/libX11.so.4
> >         libm.so.1 =>     /usr/lib/libm.so.1
> >         libc.so.1 =>     /usr/lib/libc.so.1
> >         libSM.so.6 =>    /usr/openwin/lib/libSM.so.6
> >         libICE.so.6 =>   /usr/openwin/lib/libICE.so.6
> >         libXext.so.0 =>  /usr/openwin/lib/libXext.so.0
> >         libsocket.so.1 =>        /usr/lib/libsocket.so.1
> >         libnsl.so.1 =>   /usr/lib/libnsl.so.1
> >         libdl.so.1 =>    /usr/lib/libdl.so.1
> >         libmp.so.2 =>    /usr/lib/libmp.so.2
> >         /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
> >
> > Oh well - still no clues here!
> >
> >
>

Re: remote XOpenDisplay in Solaris (SunOS 5.6)

[Jerry Miller]

I thought I had a clever idea for detection corruption in the
XOpenDisplay function.  I would simply cast the function
address to a char * and dump the contents.

Of course, I then remembered my own development of
a linker for the 6809 many years ago.  I simply reserved
space for a JMP statement to be resolved by the linker.

So it turns out that what I really need is a load map.
I've been through the man pages for ld, but the only
reference that looks relevant (but isn't) is -M.  Any
suggestions?

----- Original Message -----
From: Jerry Miller <gmiller@cs.sunysb.edu>
To: David Korn <dkorn@pixelpower.com>; <help-gcc@gnu.org>
Sent: Friday, February 23, 2001 1:37 PM
Subject: Re: remote XOpenDisplay in Solaris (SunOS 5.6)


>
> ----- Original Message -----
> From: David Korn <dkorn@pixelpower.com>
> To: 'Jerry Miller' <gmiller@cs.sunysb.edu>; <help-gcc@gnu.org>
> Sent: Friday, February 23, 2001 1:03 PM
> Subject: RE: remote XOpenDisplay in Solaris (SunOS 5.6)
>
>
> >   I believe you can probably use the 'ldd' utility to find out which
> shared
> > objects an executable needs.  If not, 'man ld.so' might point you in the
> > right direction.  As I said, though, I'm not expert with shared objects.
>
> Except for the order in which they are listed, every GUI executable
> I subjected to ldd (those that bomb opening a remote display and
> those that don't) produced the same list:
>
>         libXm.so.3 =>    /usr/lib/libXm.so.3
>         libXt.so.4 =>    /usr/openwin/lib/libXt.so.4
>         libX11.so.4 =>   /usr/openwin/lib/libX11.so.4
>         libm.so.1 =>     /usr/lib/libm.so.1
>         libc.so.1 =>     /usr/lib/libc.so.1
>         libSM.so.6 =>    /usr/openwin/lib/libSM.so.6
>         libICE.so.6 =>   /usr/openwin/lib/libICE.so.6
>         libXext.so.0 =>  /usr/openwin/lib/libXext.so.0
>         libsocket.so.1 =>        /usr/lib/libsocket.so.1
>         libnsl.so.1 =>   /usr/lib/libnsl.so.1
>         libdl.so.1 =>    /usr/lib/libdl.so.1
>         libmp.so.2 =>    /usr/lib/libmp.so.2
>         /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
>
> Oh well - still no clues here!
>
>

Re: remote XOpenDisplay in Solaris (SunOS 5.6)

[Jerry Miller]

----- Original Message -----
From: David Korn <dkorn@pixelpower.com>
To: 'Jerry Miller' <gmiller@cs.sunysb.edu>; <help-gcc@gnu.org>
Sent: Friday, February 23, 2001 1:03 PM
Subject: RE: remote XOpenDisplay in Solaris (SunOS 5.6)


>   I believe you can probably use the 'ldd' utility to find out which
shared
> objects an executable needs.  If not, 'man ld.so' might point you in the
> right direction.  As I said, though, I'm not expert with shared objects.

Except for the order in which they are listed, every GUI executable
I subjected to ldd (those that bomb opening a remote display and
those that don't) produced the same list:

        libXm.so.3 =>    /usr/lib/libXm.so.3
        libXt.so.4 =>    /usr/openwin/lib/libXt.so.4
        libX11.so.4 =>   /usr/openwin/lib/libX11.so.4
        libm.so.1 =>     /usr/lib/libm.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libSM.so.6 =>    /usr/openwin/lib/libSM.so.6
        libICE.so.6 =>   /usr/openwin/lib/libICE.so.6
        libXext.so.0 =>  /usr/openwin/lib/libXext.so.0
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1

Oh well - still no clues here!

RE: remote XOpenDisplay in Solaris (SunOS 5.6)

[David Korn]

>-----Original Message-----
>From: Jerry Miller [ mailto:gmiller@cs.sunysb.edu ]
>Sent: 23 February 2001 17:28

>I'm not sure what is dynamically linked in terms of object
>modules under UNIX in general or Solaris specifically.
>Any idea of some potential candidates?

  I believe you can probably use the 'ldd' utility to find out which shared
objects an executable needs.  If not, 'man ld.so' might point you in the
right direction.  As I said, though, I'm not expert with shared objects.

>One thing did occur to me.  Do you (or does anyone)
>know whether window managers use ipc and/or rpc
>(interprocess control and remote process control)
>routines in dealing with GUI's and other window
>managers???  And if so, is it possible to create some
>kind of "X-sniffer" on the display host to emulate the
>window manager and intercept X requests?????

  X windows certainly does, it uses straightforward RPC calls over UDP/IP
to communicate between the remote terminal and the X server, and I believe
if they are local to the same machine it will still use RPC sent over the
loopback rather than drop back to local pipes or other IPC.  tcpdump will
sniff packets for you but there is probably some other software you could
find that knows how to interpret X packets and show the commands etc. they
contain.  I'm afraid I don't know what or where though.

>Is this true of straight C code as well, e.g., ordinary static local
>functions?

  Nope, it only applies to static instances of class objects.

>I'm not using C++ at all, so I'd be really surprised if it did 
>anything more automatically than to initialize static and global variables.

  In theory the C runtime library is allowed to do whatever it wants and 
not tell you about it - that's implementation defined behaviour.  There's
no reason why the C runtime library can't be built in C++ internally, and
I rather suspect (because of the way the problem goes away when you remove
symbols from un-called functions in the same file as main) that one of 
your X or Motif libs must have some C++ in it.

>I've never heard Kernighan and Ritchie mention anything about functions 
>starting themselves with no provocation from main()!

  Well, K+R don't have anything to say about how a program gets to the
entry point of main, or what it does before it gets there.  Nor do they
impose any restrictions on it, either.  Things like opening stdin and
stdout and initialising the stdio buffers, zeroing the .bss space, and
more that don't spring to mind right now were all implicitly allowed even
by K+R.  The moral of the story is that there's a lot of dark magic going
on 'under the hood' in most compilers...

      DaveK
-- 
we are not seats or eyeballs or end users or consumers.
we are human beings - and our reach exceeds your grasp.
                    deal with it.                      - cluetrain.org 


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: remote XOpenDisplay in Solaris (SunOS 5.6)

[Jerry Miller]

----- Original Message -----
From: David Korn <dkorn@pixelpower.com>
To: 'Jerry Miller' <gmiller@cs.sunysb.edu>; <help-gcc@gnu.org>
Sent: Friday, February 23, 2001 11:46 AM
Subject: RE: remote XOpenDisplay in Solaris (SunOS 5.6)


>
> >-----Original Message-----
> >From: Jerry Miller [ mailto:gmiller@cs.sunysb.edu ]
> >Sent: 23 February 2001 16:16
>
> >Does anyone have an idea why Motif applications that
> >used to run either locally or with a remote display now
> >only work locally, causing a Segmentation fault as soon
> >as XtVaAppInitialize () (or its more primitive component,
> >XOpenDisplay()) is called in a remote-display run?
>
>   If something has suddenly changed like this, it's probably because
> you've installed a new library somewhere, which is being pulled in by
> dynamic linking, and isn't compatible with the version the application
> is expecting to find.
>
------------------------
I'm not sure what is dynamically linked in terms of object
modules under UNIX in general or Solaris specifically.
Any idea of some potential candidates?

One thing did occur to me.  Do you (or does anyone)
know whether window managers use ipc and/or rpc
(interprocess control and remote process control)
routines in dealing with GUI's and other window
managers???  And if so, is it possible to create some
kind of "X-sniffer" on the display host to emulate the
window manager and intercept X requests?????
------------------------
> >the software do not have this problem.  When I
> >#define out calls from main() to other local functions,
> >I still have it bombing, unless I also comment out a
> >number of calls to external functions from the local
> >functions that are never called!
>
>   The first thing that happens at startup of an application is that the
> constructors for any C++ class objects of static storage duration are
---------------------------
Is this true of straight C code as well, e.g., ordinary static local
functions?
I'm not using C++ at all, so I'd be really surprised if it did anything more
automatically than to initialize static and global variables.  I've never
heard
Kernighan and Ritchie mention anything about functions starting themselves
with no provocation from main()!
---------------------------
> called automagically.  It sounds like the problem is in one of these
> constructors, since removing the function calls from main doesn't make
> any difference; these constructors are called before main starts, anyway.
>
>   The reason that removing the calls in the other functions finally makes
> it work is because when they've been removed, that gets rid of all the
> references to a particular object module in the altered lib, which means
> that it doesn't get pulled in at all by the linker, which means that its
> static objects aren't pulled in, which means that the faulty constructor
> isn't run.
>
>   Note that if there is no C++ in the Motif/X libs you're using, this may
> turn out not to be the explanation after all!
>
---------------------------
I'm not aware of any.  How would I tell?  As far as I know, there are no
.hpp files in /usr/include/X11 or Xm, but libX11.a doesn't become
libX11.app.
---------------------------
> >meaningless, even in the unlikely event the
> >debugger isn't introducing its own uncertainty
> >(a la Heisenberg?)
>
>   Look up 'heisenbug' in the jargon file :)
---------------------------
:)  I can guess - it's one that goes into hiding or pops up elsewhere when
    you add a printf () or something to see what's going on, right?
---------------------------
>
> >Rather than waste any more time on trial and
> >error, I thought I'd see whether there's a
> >window manager guru out there who might
> >have answers or suggestions.
>
>   I'm not that, and nor do I really know a lot about the mysteries of
> dynamically linked libraries, but what I've suggested is certainly up
> there in the 'top five possibilities to investigate' list.  See if the
> last modified date on any of your lib files is around the time when it all
> stopped working.
>
------------------------------
Thanks for the ideas, Dave.  Every little bit helps, and I appreciate the
quick response.
------------------------------
>     hth,
>      DaveK
> --
> we are not seats or eyeballs or end users or consumers.
> we are human beings - and our reach exceeds your grasp.
>                     deal with it.                      - cluetrain.org
>
------------------------------
Heavy concept!  ;)
------------------------------
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
> www.mimesweeper.com
> **********************************************************************
>

RE: remote XOpenDisplay in Solaris (SunOS 5.6)

[David Korn]

>-----Original Message-----
>From: Jerry Miller [ mailto:gmiller@cs.sunysb.edu ]
>Sent: 23 February 2001 16:16

>Does anyone have an idea why Motif applications that
>used to run either locally or with a remote display now
>only work locally, causing a Segmentation fault as soon
>as XtVaAppInitialize () (or its more primitive component,
>XOpenDisplay()) is called in a remote-display run?

  If something has suddenly changed like this, it's probably because 
you've installed a new library somewhere, which is being pulled in by
dynamic linking, and isn't compatible with the version the application
is expecting to find.

>the software do not have this problem.  When I
>#define out calls from main() to other local functions,
>I still have it bombing, unless I also comment out a
>number of calls to external functions from the local
>functions that are never called!

  The first thing that happens at startup of an application is that the
constructors for any C++ class objects of static storage duration are 
called automagically.  It sounds like the problem is in one of these
constructors, since removing the function calls from main doesn't make
any difference; these constructors are called before main starts, anyway.

  The reason that removing the calls in the other functions finally makes
it work is because when they've been removed, that gets rid of all the
references to a particular object module in the altered lib, which means
that it doesn't get pulled in at all by the linker, which means that its
static objects aren't pulled in, which means that the faulty constructor
isn't run.

  Note that if there is no C++ in the Motif/X libs you're using, this may
turn out not to be the explanation after all!

>meaningless, even in the unlikely event the
>debugger isn't introducing its own uncertainty
>(a la Heisenberg?)

  Look up 'heisenbug' in the jargon file :)

>Rather than waste any more time on trial and
>error, I thought I'd see whether there's a
>window manager guru out there who might
>have answers or suggestions.

  I'm not that, and nor do I really know a lot about the mysteries of 
dynamically linked libraries, but what I've suggested is certainly up 
there in the 'top five possibilities to investigate' list.  See if the
last modified date on any of your lib files is around the time when it all
stopped working.

    hth, 
     DaveK
-- 
we are not seats or eyeballs or end users or consumers.
we are human beings - and our reach exceeds your grasp.
                    deal with it.                      - cluetrain.org 


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

remote XOpenDisplay in Solaris (SunOS 5.6)

[Jerry Miller]

Does anyone have an idea why Motif applications that
used to run either locally or with a remote display now
only work locally, causing a Segmentation fault as soon
as XtVaAppInitialize () (or its more primitive component,
XOpenDisplay()) is called in a remote-display run?

I am able to run the PC (Interix) version of the same
software with either a local (HWM) or remote (olwm)
display, but the Solaris versions bomb on a remote
display attempt.  Older, less complex versions of
the software do not have this problem.  When I
#define out calls from main() to other local functions,
I still have it bombing, unless I also comment out a
number of calls to external functions from the local
functions that are never called!

It almost seems as if there is a memory-management
problem, despite having 1/2Gb RAM on the Suns,
such that creating too large an executable (over 3Mb)
causes a conflict with communications overhead?!?!
The executables that don't bomb are around 2Mb.

Using gdb to try to find the answer is no help.
It does tell me that the crash (apparently) occurs
in one of many calls to strlen() from within
XtVaAppInitialize(), but with all this opaque code
(not to mention that X and Motif are flaky in lots
of other ways), that information is totally
meaningless, even in the unlikely event the
debugger isn't introducing its own uncertainty
(a la Heisenberg?)

It's hard to know exactly when this started,
because we hadn't been trying remote displays
on a daily or weekly basis.  I might try
switching from the common desktop environment
back to the openwin environment the next time
I logout, which I very seldom do.

Rather than waste any more time on trial and
error, I thought I'd see whether there's a
window manager guru out there who might
have answers or suggestions.