NNTP-Posting-Date: Sun, 10 Nov 2002 14:09:54 -0600
From: Charles Wilkins <chas AT pcscs DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: i686-pc-msdosdjgpp-g++ problems (long)
Date: Sun, 10 Nov 2002 15:11:50 -0500
Message-ID: <85ctsu00ta2hiln51cm74ug0589tk0rp86@4ax.com>
References: <lrplsuounbjm9n878rvu4e4sobqofcu437 AT 4ax DOT com> <aqfvt3$6t$1 AT antares DOT lu DOT erisoft DOT se> <taunsusrk60vfe987b0a0ncp0u2cqkh7of AT 4ax DOT com> <1036779663 DOT 158618 AT queeg DOT ludd DOT luth DOT se> <1h6osuka51oan46817ptm2o1loq3k6fqm7 AT 4ax DOT com> <200211082039 DOT gA8Kdck00835 AT envy DOT delorie DOT com> <c5aosuktk341qeu7fj7gj8954a32ktpk1a AT 4ax DOT com> <1036845028 DOT 195290 AT queeg DOT ludd DOT luth DOT se> <si3qsugank9hsrjrig0m72dne3rb8gm6hj AT 4ax DOT com> <1036944551 DOT 298873 AT queeg DOT ludd DOT luth DOT se>
X-Newsreader: Forte Agent 1.92/32.570
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 195
NNTP-Posting-Host: 68.45.75.113
X-Trace: sv3-2B5XdJTfw7XC1Dc7xbmVZgZpbTvmu6lwNMJ2uh4mCffkiS90nS0TmHv0Qn08Y+Mf9i3qGhYkq2kavcq!df35nMAKHrkDCKpG8mZliKODL8HzYcVXEagxvvZHss/8HO+xMkxHlp7lX+kgq3OSUaSJgf8=
X-Complaints-To: abuse AT comcast DOT com
X-DMCA-Complaints-To: dmca AT comcast DOT net
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.1
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

>Ok. Now do "br 0x0001f47f" or "br *0x0001f47f" (I forget the exact
>syntax) and "run". Now you should stop just before the crash. Examine
>the registers and figure out what's wrong. Do "disass 0x0001f47f" or
>"disass *0x0001f47f" to see the exact machine instruction that
>crashes.

C:\Archives\RIP2\DJGPP\bin>gdb wel-g.exe
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-pc-msdosdjgpp"...
(gdb) run
Starting program: c:/Archives/RIP2/DJGPP/bin/wel-g.exe

Program received signal SIGSEGV, Segmentation fault.
0x0001e1df in std::ostream::sentry::sentry(std::ostream&) ()
(gdb) n
Single stepping until exit from function _ZNSo6sentryC1ERSo,
which has no line number information.
Exiting due to signal SIGSEGV
General Protection Fault at eip=0001e1df
eax=00000000 ebx=00043b58 ecx=00043b58 edx=000c7f60 esi=00000054
edi=00001630
ebp=000c7f28 esp=000c7f24 program=c:\Archives\RIP2\DJGPP\bin\wel-g.exe
cs: sel=01ef  base=022c0000  limit=000cffff
ds: sel=01f7  base=022c0000  limit=000cffff
es: sel=01f7  base=022c0000  limit=000cffff
fs: sel=01e7  base=0001a250  limit=00003fff
gs: sel=0207  base=00000000  limit=0010ffff
ss: sel=01f7  base=022c0000  limit=000cffff
App stack: [000c7fdc..00047fdc]  Exceptn stack: [00047e8c..00045f4c]

Call frame traceback EIPs:
  0x0001e1df
  0x0001e44e
  0x0000167e
  0x0000d817

Program exited with code 0377.
(gdb) br *0x0001e1df
Breakpoint 1 at 0x1e1df

(gdb) run
Starting program: c:/Archives/RIP2/DJGPP/bin/wel-g.exe

Breakpoint 1, 0x0001e1df in
std::ostream::sentry::sentry(std::ostream&) ()
(gdb) disass 0x0001e1df
Dump of assembler code for function _ZNSo6sentryC1ERSo:
0x1e1d0 <_ZNSo6sentryC1ERSo>:        push   %ebp
0x1e1d1 <_ZNSo6sentryC1ERSo+1>:        mov    %esp,%ebp
0x1e1d3 <_ZNSo6sentryC1ERSo+3>:        push   %ebx
0x1e1d4 <_ZNSo6sentryC1ERSo+4>:        mov    0xc(%ebp),%ecx
0x1e1d7 <_ZNSo6sentryC1ERSo+7>:        mov    0x8(%ebp),%edx
0x1e1da <_ZNSo6sentryC1ERSo+10>:        mov    (%ecx),%eax
0x1e1dc <_ZNSo6sentryC1ERSo+12>:        mov    %ecx,0x4(%edx)
0x1e1df <_ZNSo6sentryC1ERSo+15>:        mov    0xfffffff4(%eax),%ebx
0x1e1e2 <_ZNSo6sentryC1ERSo+18>:        lea    (%ebx,%ecx,1),%eax
0x1e1e5 <_ZNSo6sentryC1ERSo+21>:        mov    0x14(%eax),%ebx
0x1e1e8 <_ZNSo6sentryC1ERSo+24>:        test   %ebx,%ebx
0x1e1ea <_ZNSo6sentryC1ERSo+26>:        sete   %al
0x1e1ed <_ZNSo6sentryC1ERSo+29>:        movzbl %al,%eax
0x1e1f0 <_ZNSo6sentryC1ERSo+32>:        test   %al,%al
0x1e1f2 <_ZNSo6sentryC1ERSo+34>:        mov    %al,(%edx)
0x1e1f4 <_ZNSo6sentryC1ERSo+36>:        je     0x1e210
<_ZNSo6sentryC1ERSo+64>
0x1e1f6 <_ZNSo6sentryC1ERSo+38>:        mov    (%ecx),%eax
0x1e1f8 <_ZNSo6sentryC1ERSo+40>:        mov    0xfffffff4(%eax),%edx
0x1e1fb <_ZNSo6sentryC1ERSo+43>:        add    %edx,%ecx
0x1e1fd <_ZNSo6sentryC1ERSo+45>:        mov    0x70(%ecx),%eax
0x1e200 <_ZNSo6sentryC1ERSo+48>:        test   %eax,%eax
0x1e202 <_ZNSo6sentryC1ERSo+50>:        je     0x1e210
<_ZNSo6sentryC1ERSo+64>
0x1e204 <_ZNSo6sentryC1ERSo+52>:        mov    %eax,0x8(%ebp)
0x1e207 <_ZNSo6sentryC1ERSo+55>:        pop    %ebx
0x1e208 <_ZNSo6sentryC1ERSo+56>:        pop    %ebp
0x1e209 <_ZNSo6sentryC1ERSo+57>:        jmp    0x1dde0 <_ZNSo5flushEv>
0x1e20e <_ZNSo6sentryC1ERSo+62>:        mov    %esi,%esi
0x1e210 <_ZNSo6sentryC1ERSo+64>:        pop    %ebx
0x1e211 <_ZNSo6sentryC1ERSo+65>:        pop    %ebp
0x1e212 <_ZNSo6sentryC1ERSo+66>:        ret
0x1e213 <_ZNSo6sentryC1ERSo+67>:        nop
0x1e214 <_ZNSo6sentryC1ERSo+68>:        nop
0x1e215 <_ZNSo6sentryC1ERSo+69>:        nop
0x1e216 <_ZNSo6sentryC1ERSo+70>:        nop
0x1e217 <_ZNSo6sentryC1ERSo+71>:        nop
0x1e218 <_ZNSo6sentryC1ERSo+72>:        nop
0x1e219 <_ZNSo6sentryC1ERSo+73>:        nop
0x1e21a <_ZNSo6sentryC1ERSo+74>:        nop
0x1e21b <_ZNSo6sentryC1ERSo+75>:        nop
0x1e21c <_ZNSo6sentryC1ERSo+76>:        nop
0x1e21d <_ZNSo6sentryC1ERSo+77>:        nop
0x1e21e <_ZNSo6sentryC1ERSo+78>:        nop
0x1e21f <_ZNSo6sentryC1ERSo+79>:        nop
End of assembler dump.
(gdb)

>Get the C++ file that contains that
>std::ostream::sentry::sentry(std::ostream&) () and add it to the
>compile line after welcome.cpp. Now you might get the source
>displayed.

No C++ file contains std::ostream::sentry::sentry(std::ostream&) ()

Here are some greps that returned files.
cd /usr/local/compiler/cross4/djgpp

grep -lr . -e '::sentry::'
./include/c++/3.2/bits/istream.tcc
./include/c++/3.2/bits/ostream.tcc

These are header files.

grep -lr . -e 'sentry'
./i686-pc-msdosdjgpp/lib/libstdcxx.a
./i686-pc-msdosdjgpp/lib/libstdc++.a
./lib/gcc-lib/i686-pc-msdosdjgpp/3.2/cc1plus
./include/c++/3.2/bits/istream.tcc
./include/c++/3.2/bits/ostream.tcc
./include/c++/3.2/bitset
./include/c++/3.2/istream
./include/c++/3.2/ostream

grep -lr . -e '_ZNSo6sentryC1ERSo'
./i686-pc-msdosdjgpp/lib/libstdcxx.a
./i686-pc-msdosdjgpp/lib/libstdc++.a


More detailed directory listings of those files.

ls -l $(echo $(grep -lr . -e '::sentry::'))
-rw-r--r--    1 root     root        35353 Nov 10 11:48
./include/c++/3.2/bits/istream.tcc
-rw-r--r--    1 root     root        20812 Nov 10 11:48
./include/c++/3.2/bits/ostream.tcc

ls -l $(echo $(grep -lr . -e 'sentry'))
-rw-r--r--    1 root     root      3708034 Nov 10 11:49
./i686-pc-msdosdjgpp/lib/libstdc++.a
lrwxrwxrwx    1 root     root           11 Nov 10 11:51
./i686-pc-msdosdjgpp/lib/libstdcxx.a -> libstdc++.a
-rw-r--r--    1 root     root        35353 Nov 10 11:48
./include/c++/3.2/bits/istream.tcc
-rw-r--r--    1 root     root        20812 Nov 10 11:48
./include/c++/3.2/bits/ostream.tcc
-rw-r--r--    1 root     root        33917 Nov 10 11:49
./include/c++/3.2/bitset
-rw-r--r--    1 root     root         8757 Nov 10 11:49
./include/c++/3.2/istream
-rw-r--r--    1 root     root         8481 Nov 10 11:49
./include/c++/3.2/ostream
-rwxr-xr-x    1 root     root      7643951 Nov 10 11:48
./lib/gcc-lib/i686-pc-msdosdjgpp/3.2/cc1plus*

ls -l $(echo $(grep -lr . -e '_ZNSo6sentryC1ERSo'))
-rw-r--r--    1 root     root      3708034 Nov 10 11:49
./i686-pc-msdosdjgpp/lib/libstdc++.a
lrwxrwxrwx    1 root     root           11 Nov 10 11:51
./i686-pc-msdosdjgpp/lib/libstdcxx.a -> libstdc++.a


Just as a sidenote (possibly re-iterated)
The SIGSEGV occurs only when I include the iostream header (I haven't
tested any others yet) from the C++ standard library in my program.
The g++ compiler builds the exectutable without error, but the
executable segment faults when I try to run it under DOS or Win32.

The SIGSEGV does not occur when I include C standard library headers.
gcc and g++ cross compiled executables built using only Standard C
headers run fine under DOS and Win32.

Could this problem be resulting from the libstdc++.a archive library
having a name that defies DOS naming conventions?  .. just a shot  in
the dark

Another question WRT the FAQ at:
http://www.delorie.com/djgpp/v2faq/faq22_9.html

One of the steps WRT the build.cross script (which I haven't tried)
is:

DJGPP C++ headers (from the gppNNNb.zip package) are in the
prefix/i586-pc-msdosdjgpp/lang/cxx directory; 

I have not done this.. Should I be?
I have been building soley from the gcc-3.2 release sources.

Charles