public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* RE: libstdc++/9828: Regression: Segmentation fault in num_put::put
@ 2003-04-03 15:46 Pétur Runólfsson
0 siblings, 0 replies; 11+ messages in thread
From: Pétur Runólfsson @ 2003-04-03 15:46 UTC (permalink / raw)
To: jlquinn; +Cc: gcc-prs
The following reply was made to PR libstdc++/9828; it has been noted by GNATS.
From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02@ru.is>
To: "Jerry Quinn" <jlquinn@optonline.net>,
<paolo@gcc.gnu.org>,
<gcc-bugs@gcc.gnu.org>,
<nobody@gcc.gnu.org>,
<gcc-gnats@gcc.gnu.org>
Cc: <libstdc++@gcc.gnu.org>
Subject: RE: libstdc++/9828: Regression: Segmentation fault in num_put::put
Date: Thu, 3 Apr 2003 15:36:27 -0000
Jerry Quinn wrote:
> Another is that locales carry the cache info to avoid this problem.
I think this might be the best solution; it is very common to
create a stringstream just to format one number (see for
example boost::lexical_cast or operator<<(ostream&, complex&)).
Storing the cache in the locale would allow such code to take
advantage of the caches.
It should be easy to implement this using the same techniques
as are used for storing facets in locales.
Regards,
Petur
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
@ 2003-04-03 16:36 Benjamin Kosnik
0 siblings, 0 replies; 11+ messages in thread
From: Benjamin Kosnik @ 2003-04-03 16:36 UTC (permalink / raw)
To: jlquinn; +Cc: gcc-prs
The following reply was made to PR libstdc++/9828; it has been noted by GNATS.
From: Benjamin Kosnik <bkoz@redhat.com>
To: Benjamin Kosnik <bkoz@redhat.com>
Cc: peturr02@ru.is, jlquinn@optonline.net, paolo@gcc.gnu.org,
gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
libstdc++@gcc.gnu.org
Subject: Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
Date: Thu, 3 Apr 2003 10:28:18 -0600
The other advantage of this approach is that it's more extensible: we
could add more caches as we get the time, and not have to worry about
the size of __locale_cache changing, adding more accessor functions, and
link map maneuvering.
I'd been a bit worried about this, since large parts of the locale
facets haven't yet been caches (floating point numerics, everything
else).
-benjamin
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
@ 2003-04-03 16:26 Benjamin Kosnik
0 siblings, 0 replies; 11+ messages in thread
From: Benjamin Kosnik @ 2003-04-03 16:26 UTC (permalink / raw)
To: jlquinn; +Cc: gcc-prs
The following reply was made to PR libstdc++/9828; it has been noted by GNATS.
From: Benjamin Kosnik <bkoz@redhat.com>
To: Benjamin Kosnik <bkoz@redhat.com>
Cc: peturr02@ru.is, jlquinn@optonline.net, paolo@gcc.gnu.org,
gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
libstdc++@gcc.gnu.org
Subject: Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
Date: Thu, 3 Apr 2003 10:17:06 -0600
>Yep. This is what I was talking about when this first went in, abit very
>vaguely. If you could do something like has_cache/use_cache as analogues
>to has_facet/has_cache I think we'll be better off.
Ugh. I mean: has_cache/use_cache like has_facet/use_facet! I didn't get
this right the first time I posted it.
Also, this will make the zero-allocation bits easier to do. (We need a
way to do zero allocation for both the standard streams, and for the
future, when persistent streams are done.)
best,
benjamin
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
@ 2003-04-03 16:16 Benjamin Kosnik
0 siblings, 0 replies; 11+ messages in thread
From: Benjamin Kosnik @ 2003-04-03 16:16 UTC (permalink / raw)
To: jlquinn; +Cc: gcc-prs
The following reply was made to PR libstdc++/9828; it has been noted by GNATS.
From: Benjamin Kosnik <bkoz@redhat.com>
To: =?ISO-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02@ru.is>
Cc: jlquinn@optonline.net, paolo@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org, libstdc++@gcc.gnu.org
Subject: Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
Date: Thu, 3 Apr 2003 10:13:13 -0600
>> Another is that locales carry the cache info to avoid this problem.
Yes. This is what I'd really prefer. That way the cache is available to
everybody, not just the io code.
>I think this might be the best solution; it is very common to
>create a stringstream just to format one number (see for
>example boost::lexical_cast or operator<<(ostream&, complex&)).
>Storing the cache in the locale would allow such code to take
>advantage of the caches.
>
>It should be easy to implement this using the same techniques
>as are used for storing facets in locales.
Yep. This is what I was talking about when this first went in, abit very
vaguely. If you could do something like has_cache/use_cache as analogues
to has_facet/has_cache I think we'll be better off.
-benjamin
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
@ 2003-04-03 14:46 Jerry Quinn
0 siblings, 0 replies; 11+ messages in thread
From: Jerry Quinn @ 2003-04-03 14:46 UTC (permalink / raw)
To: jlquinn; +Cc: gcc-prs
The following reply was made to PR libstdc++/9828; it has been noted by GNATS.
From: Jerry Quinn <jlquinn@optonline.net>
To: paolo@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org,
peturr02@ru.is, gcc-gnats@gcc.gnu.org
Cc: libstdc++@gcc.gnu.org
Subject: Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
Date: Thu, 03 Apr 2003 09:41:47 -0500
paolo@gcc.gnu.org writes:
> Synopsis: Regression: Segmentation fault in num_put::put
>
> Responsible-Changed-From-To: unassigned->jlquinn
> Responsible-Changed-By: paolo
> Responsible-Changed-When: Mon Mar 24 13:16:11 2003
> Responsible-Changed-Why:
> Jerry, I'm tentatively assigning this one to you: the problem
> appear in your new _M_convert_int and _M_group_int.
> State-Changed-From-To: open->analyzed
> State-Changed-By: paolo
> State-Changed-When: Mon Mar 24 13:16:11 2003
> State-Changed-Why:
> Confirmed 3.3 and 3.4.
>
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9828
OK, I can see why the crash is happening now. In the test program, we
have:
typedef num_put<wchar_t> npw_t;
wostringstream stream;
const npw_t& npw = use_facet<npw_t>(stream.getloc());
npw.put(stream, cout, L' ', static_cast<long>(10));
In particular, we're calling num_put<wchar_t>::put with
basic_ostream<char>. The printing code pulls the locale_cache from
the ios_base that is provided - in this case, cout. But the code
assumes that the cache provided by ios_base is instantiated with the
same type as the num_put class, and hence that the ios_base is a base
class for an ostream that was also instantiated with that type.
In this failure, cout provides __locale_cache<char>, but we interpret
it as __locale_cache<wchar_t> and things go downhill from there.
This is ugly! To make this work, we need to get
__locale_cache<wchar_t> from somewhere, in sync with the facet being
used for printing.
I'm open to suggestions here. As is, we're trading one regression for
another - and the performance regression without the locale cache
stuff is pretty bad.
One possibility is that ios_base would have to be able to provide a
cache for any type that is asked for - seems ugly.
Another is that locales carry the cache info to avoid this problem.
Or perhaps the facets cache the info required, but that may get into
overlaps of info between facets.
Jerry Quinn
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
@ 2003-03-25 13:46 jlquinn
0 siblings, 0 replies; 11+ messages in thread
From: jlquinn @ 2003-03-25 13:46 UTC (permalink / raw)
To: jlquinn; +Cc: gcc-prs
The following reply was made to PR libstdc++/9828; it has been noted by GNATS.
From: jlquinn@optonline.net
To: Paolo Carlini <pcarlini@unitus.it>
Cc: gcc-gnats@gcc.gnu.org, peturr02@ru.is, gcc-bugs@gcc.gnu.org,
jlquinn@gcc.gnu.org
Subject: Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
Date: Tue, 25 Mar 2003 08:34:28 -0500
Paolo Carlini writes:
> Hi Jerry,
>
> on i686-pc-linux-gnu it's very easy to reproduce here, no special options, both
> 3.3 and 3.4. The seg fault happens when _M_group_int tries to use __grouping,
> in particular __grouping.size(). In _M_convert_int, __lc._M_use_grouping is equal
> to 4 (true), but __lc._M_grouping is not a valid string:
>
> (gdb) print __lc._M_grouping.data()
> $3 = 0x0
>
> Paolo.
Huh. WHat I had done was check out 3.3 on i686-pc-linux-gnu, and
configure --with-system-zlib --enable-threads --with-cpu=athlon
--program-suffix=3.3.
I can rebootstrap with no options and see what happens.
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9828
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
@ 2003-03-25 13:15 Paolo Carlini
0 siblings, 0 replies; 11+ messages in thread
From: Paolo Carlini @ 2003-03-25 13:15 UTC (permalink / raw)
To: jlquinn; +Cc: gcc-prs
The following reply was made to PR libstdc++/9828; it has been noted by GNATS.
From: Paolo Carlini <pcarlini@unitus.it>
To: gcc-gnats@gcc.gnu.org, peturr02@ru.is, gcc-bugs@gcc.gnu.org,
gcc-prs@gcc.gnu.org, jlquinn@gcc.gnu.org
Cc:
Subject: Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
Date: Tue, 25 Mar 2003 14:06:31 +0100
Jerry, this is a backtrace:
(gdb) run
Program received signal SIGSEGV, Segmentation fault.
0x400a5ac9 in std::string::size() const (this=0x8049fd8) at
/home/paolo/Gcc/cvs-dirs/gcc-3_3-branch-build/i686-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:408
/home/paolo/Gcc/cvs-dirs/gcc-3_3-branch-build/i686-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:408:13153:beg:0x400a5ac9
(gdb) backtrace
#0 0x400a5ac9 in std::string::size() const (this=0x8049fd8) at
/home/paolo/Gcc/cvs-dirs/gcc-3_3-branch-build/i686-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:408
#1 0x400a7bd9 in std::string::c_str() const (this=0x8049fd8) at
/home/paolo/Gcc/cvs-dirs/gcc-3_3-branch-build/i686-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:803
#2 0x40081750 in std::num_put<wchar_t, std::ostreambuf_iterator<wchar_t, std::char_traits<wchar_t> > >::_M_group_int(std::string const&, wchar_t,
std::ios_base&, wchar_t*, wchar_t*, int&) const (this=0x400e3d68, __grouping=@0x8049fd8, __sep=101, __io=@0x8049e50, __new=0xbffff41c,
__cs=0xbffff464, __len=@0xbffff484) at /home/paolo/Gcc/cvs-dirs/gcc-3_3-branch-build/i686-pc-linux-gnu/libstdc++-v3/include/bits/locale_facets.tcc:757
#3 0x400825e0 in std::ostreambuf_iterator<wchar_t, std::char_traits<wchar_t> > std::num_put<wchar_t, std::ostreambuf_iterator<wchar_t,
std::char_traits<wchar_t> > >::_M_convert_int<long>(std::ostreambuf_iterator<wchar_t, std::char_traits<wchar_t> >, std::ios_base&, wchar_t, long)
const (this=0x400e3d68, __s={<iterator<std::output_iterator_tag,void,void,void,void>> = {<No data fields>}, _M_sbuf = 0xbffff594, _M_failed = false},
__io=@0x8049e50, __fill=32, __v=10) at /home/paolo/Gcc/cvs-dirs/gcc-3_3-branch-build/i686-pc-linux-gnu/libstdc++-v3/include/bits/locale_facets.tcc:794
#4 0x4008213a in std::num_put<wchar_t, std::ostreambuf_iterator<wchar_t, std::char_traits<wchar_t> > >::do_put(std::ostreambuf_iterator<wchar_t,
std::char_traits<wchar_t> >, std::ios_base&, wchar_t, long) const (this=0x400e3d68, __s={<iterator<std::output_iterator_tag,void,void,void,void>> =
{<No data fields>}, _M_sbuf = 0xbffff594, _M_failed = false}, __io=@0x8049e50, __fill=32, __v=10) at
/home/paolo/Gcc/cvs-dirs/gcc-3_3-branch-build/i686-pc-linux-gnu/libstdc++-v3/include/bits/locale_facets.tcc:1008
#5 0x4008134d in std::num_put<wchar_t, std::ostreambuf_iterator<wchar_t, std::char_traits<wchar_t> > >::put(std::ostreambuf_iterator<wchar_t,
std::char_traits<wchar_t> >, std::ios_base&, wchar_t, long) const (this=0x400e3d68, __s={<iterator<std::output_iterator_tag,void,void,void,void>> =
{<No data fields>}, _M_sbuf = 0xbffff594, _M_failed = false}, __f=@0x8049e50, __fill=32, __v=10) at
/home/paolo/Gcc/cvs-dirs/gcc-3_3-branch-build/i686-pc-linux-gnu/libstdc++-v3/include/bits/locale_facets.h:866
#6 0x080489be in main () at 9828.cc:13
#7 0x40135ca6 in __libc_start_main (main=0x80488d4 <main>, argc=1, ubp_av=0xbffff6e4, init=0x8048b10 <__libc_csu_init>, fini=0x8048b40
<__libc_csu_fini>, rtld_fini=0x400158c0 <_rtld_local>, stack_end=0xbffff464) at ../sysdeps/generic/libc-start.c:152
Paolo.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9828
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
@ 2003-03-25 13:06 Paolo Carlini
0 siblings, 0 replies; 11+ messages in thread
From: Paolo Carlini @ 2003-03-25 13:06 UTC (permalink / raw)
To: jlquinn; +Cc: gcc-prs
The following reply was made to PR libstdc++/9828; it has been noted by GNATS.
From: Paolo Carlini <pcarlini@unitus.it>
To: gcc-gnats@gcc.gnu.org, peturr02@ru.is, gcc-bugs@gcc.gnu.org,
gcc-prs@gcc.gnu.org, jlquinn@gcc.gnu.org
Cc:
Subject: Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
Date: Tue, 25 Mar 2003 14:02:05 +0100
Hi Jerry,
on i686-pc-linux-gnu it's very easy to reproduce here, no special options, both
3.3 and 3.4. The seg fault happens when _M_group_int tries to use __grouping,
in particular __grouping.size(). In _M_convert_int, __lc._M_use_grouping is equal
to 4 (true), but __lc._M_grouping is not a valid string:
(gdb) print __lc._M_grouping.data()
$3 = 0x0
Paolo.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9828
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
@ 2003-03-25 6:46 Jerry Quinn
0 siblings, 0 replies; 11+ messages in thread
From: Jerry Quinn @ 2003-03-25 6:46 UTC (permalink / raw)
To: jlquinn; +Cc: gcc-prs
The following reply was made to PR libstdc++/9828; it has been noted by GNATS.
From: Jerry Quinn <jlquinn@optonline.net>
To: gcc-gnats@gcc.gnu.org, peturr02@ru.is, gcc-bugs@gcc.gnu.org,
gcc-prs@gcc.gnu.org, jlquinn@gcc.gnu.org
Cc:
Subject: Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
Date: Tue, 25 Mar 2003 01:00:08 -0500
This test works for me on 3.3. Checked out around midnight March
24. I'll try 3.4 tomorrow.
Any advice on how to reproduce the crash in 3.3?
Jerry Quinn
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: libstdc++/9828: Regression: Segmentation fault in num_put::put
@ 2003-03-24 13:41 paolo
0 siblings, 0 replies; 11+ messages in thread
From: paolo @ 2003-03-24 13:41 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, jlquinn, nobody, peturr02
Synopsis: Regression: Segmentation fault in num_put::put
Responsible-Changed-From-To: unassigned->jlquinn
Responsible-Changed-By: paolo
Responsible-Changed-When: Mon Mar 24 13:16:11 2003
Responsible-Changed-Why:
Jerry, I'm tentatively assigning this one to you: the problem
appear in your new _M_convert_int and _M_group_int.
State-Changed-From-To: open->analyzed
State-Changed-By: paolo
State-Changed-When: Mon Mar 24 13:16:11 2003
State-Changed-Why:
Confirmed 3.3 and 3.4.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9828
^ permalink raw reply [flat|nested] 11+ messages in thread
* libstdc++/9828: Regression: Segmentation fault in num_put::put
@ 2003-02-24 9:26 peturr02
0 siblings, 0 replies; 11+ messages in thread
From: peturr02 @ 2003-02-24 9:26 UTC (permalink / raw)
To: gcc-gnats
>Number: 9828
>Category: libstdc++
>Synopsis: Regression: Segmentation fault in num_put::put
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Feb 24 09:26:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator: peturr02@ru.is
>Release: gcc version 3.4 20030222 (experimental)
>Organization:
>Environment:
Red Hat Linux 8.0.
>Description:
num_put<CharT>::put causes a segmentation fault if the ios_base argument is not an object of type basic_ios<CharT, Traits> (for example if CharT is wchar_t and cout is used for the ios_base argument). This works OK in gcc-3.2.1.
>How-To-Repeat:
See attachment.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: text/plain; name="mixmodebug.cc"
Content-Disposition: inline; filename="mixmodebug.cc"
#include <sstream>
#include <iostream>
#include <locale>
int main()
{
using namespace std;
typedef num_put<wchar_t> npw_t;
wostringstream stream;
const npw_t& npw = use_facet<npw_t>(stream.getloc());
npw.put(stream, cout, L' ', static_cast<long>(10));
return 0;
}
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2003-04-03 16:36 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-04-03 15:46 libstdc++/9828: Regression: Segmentation fault in num_put::put Pétur Runólfsson
-- strict thread matches above, loose matches on Subject: below --
2003-04-03 16:36 Benjamin Kosnik
2003-04-03 16:26 Benjamin Kosnik
2003-04-03 16:16 Benjamin Kosnik
2003-04-03 14:46 Jerry Quinn
2003-03-25 13:46 jlquinn
2003-03-25 13:15 Paolo Carlini
2003-03-25 13:06 Paolo Carlini
2003-03-25 6:46 Jerry Quinn
2003-03-24 13:41 paolo
2003-02-24 9:26 peturr02
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).