--- Comment #6 from pcarlini at suse dot de 2007-03-27 18:07 ---
To restate my point: if, with a recent compiler, I change the testcase to use
ext/vstring.h, which has completely different memory management, instead of
string, even for plain char I get an immediate Segmentation Fault
--- Comment #7 from gregoryk at edifecs dot com 2007-03-27 18:20 ---
Unfortunately I do not have possibility to run my test case using latest GCC
compiler. Im limited in hardware and software choice. Besides Im not sure
what do you mean to fix testcase. If you could fix it then it
--- Comment #8 from pcarlini at suse dot de 2007-03-27 18:24 ---
(In reply to comment #7)
Unfortunately I do not have possibility to run my test case using latest GCC
compiler. Im limited in hardware and software choice. Besides Im not sure
what do you mean to fix testcase.
As I
--- Comment #9 from pcarlini at suse dot de 2007-03-27 18:36 ---
I get an immediate Segmentation fault even if I change read_string to do
nothing..
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
--- Comment #10 from gregoryk at edifecs dot com 2007-03-27 18:39 ---
Got it, thanks. In may original test I was relaying on LD_LIBRARY_PATH to have
current folder in the values. And there was no checking of dlopen result for
simplicity. Here is updated code. It will search for
--- Comment #11 from gregoryk at edifecs dot com 2007-03-27 18:40 ---
Forgot to mention, that was main.cpp code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
--- Comment #12 from pcarlini at suse dot de 2007-03-27 19:22 ---
Ok, now I see. The kind of issue is unfortunately known, akin to 24196 for
example, and ultimately due to the special, optimized way we are dealing with
empty strings, not allocating dynamic memory at all. I don't think
--- Comment #13 from pcarlini at suse dot de 2007-03-27 19:25 ---
By the way, as a matter of portability, isn't a good idea to use the string
class with anything != char and wchar_t: things usually work in rather recent
releases of GCC only because we are delivering a generic
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
|
--- Comment #14 from gregoryk at edifecs dot com 2007-03-27 19:51 ---
Thank you for info. The sample is working now with
_GLIBCXX_FULLY_DYNAMIC_STRING turned on. What is the next procedure with bug
status? For me bug can be marked as FIXED.
Regarding portability. We use unsigned short
--- Comment #15 from pcarlini at suse dot de 2007-03-27 19:53 ---
Ok, I will mark it as suspended, because when we break the binary compatibility
things will always work fine.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2007-03-26 22:10 ---
Seems the same as libstdc++/25956. Can you try whether instantiating the string
class at global scope works for you too:
http://gcc.gnu.org/ml/libstdc++/2006-01/msg00162.html
???
--
--- Comment #2 from gregoryk at edifecs dot com 2007-03-26 22:28 ---
Though the problem from bug 25956 looks same the instantiating didn't help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
--- Comment #3 from pcarlini at suse dot de 2007-03-26 22:52 ---
Ok, but before we take any further action we badly need a better reproduce: on
any up to date x86 and x86-64 linux machine I tried, your testcase segfault
immediately both for unsigned short and for char (and the
--- Comment #4 from gregoryk at edifecs dot com 2007-03-26 23:13 ---
Ok. Can I help you somehow?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31368
--- Comment #5 from pcarlini at suse dot de 2007-03-26 23:24 ---
Yes, as I said, we need a better reproducer, that is a testcase that on most of
the current x86-linux or x86-64-linux machines behaves as you are reporting: if
you want to help you should look for a recent machine (e.g.,
16 matches
Mail list logo
