libstc++ (?) problem on CURRENT?
I had a problem running the IcedTea java plugin on CURRENT i386, while it works on 8_STABLE. But maybe it's not a problem related to the port. Just to be clear, I'm not looking for a solution about the port here, I'm just wondering why the same c++ code is working on 8_STABLE and it's segfaulting on CURRENT, considering also that AFAIK the gcc version in both the base systems is the same. In the part of the code causing the crash, a std::map is read with an iterator in a for loop, and if a condition is met, an entry is erased. The following is the bt I'm getting: #0 0x29e36247 in kill () from /lib/libc.so.7 #1 0x29e361a6 in raise () from /lib/libc.so.7 #2 0x282424f6 in XRE_LockProfileDirectory () from /usr/local/lib/firefox3/libxul.so #3 signal handler called #4 0x29c8f1b2 in std::_Rb_tree_increment () from /usr/lib/libstdc++.so.6 #5 0x2ef92402 in IcedTeaPluginUtilities::invalidateInstance () from /usr/local/openjdk6/jre/lib/IcedTeaPlugin.so ... I wrote a patch for the IcedTea plugin, replacing the for loop with a while and increasing the iterator before erasing from the map, and it seems working. Then I wrote a simple program that do something similar to IcedTea, so there is no need to build the whole java/openjdk6 port to do some testing. Running it on 8_STABLE it works, on CURRENT it crashes. You can find more details in this discussion on the freebsd-java ml: http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html You can find the patch and the sample code in the discussion above, anyway I'm reporting them here too: icedtea patch: http://pastebin.com/b2KKFNSG test case: http://pastebin.com/Amk4UJ0g I hope that the crash is not caused by a bad environment, can anyone else test it? Thanks Barbara ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libstc++ (?) problem on CURRENT?
* Barbara barbara.xxx1...@libero.it, 20101106 10:57: Just to be clear, I'm not looking for a solution about the port here, I'm just wondering why the same c++ code is working on 8_STABLE and it's segfaulting on CURRENT, considering also that AFAIK the gcc version in both the base systems is the same. I am a real STL newbie, so I could be wrong. Maybe it's not allowed to remove an element in the map you're currently iterating. Therefore you're accessing memory which has been deallocated. This may crash on HEAD and not on 8-STABLE for various reasons. For example, malloc() in HEAD has all sorts of debugging options enabled, while 8-STABLE does not. Greetings, -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpVzkBGkeJh8.pgp Description: PGP signature
R: Re: libstc++ (?) problem on CURRENT?
* Barbara barbara.xxx1...@libero.it, 20101106 10:57: Just to be clear, I'm not looking for a solution about the port here, I'm just wondering why the same c++ code is working on 8_STABLE and it's segfaulting on CURRENT, considering also that AFAIK the gcc version in both the base systems is the same. I am a real STL newbie, so I could be wrong. Maybe it's not allowed to remove an element in the map you're currently iterating. Therefore you're accessing memory which has been deallocated. I'm sure you're not worse than me! :) Anyway that's what I was thinking when I wrote the patch. This may crash on HEAD and not on 8-STABLE for various reasons. For example, malloc() in HEAD has all sorts of debugging options enabled, while 8-STABLE does not. So you think that the problem is really in the original source code, but exposed only on CURRENT. That could be an option. Thanks Barbara ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
But maybe it's not a problem related to the port.
Just to be clear, I'm not looking for a solution about the port here, I'm
just
wondering why the same c++ code is working on 8_STABLE and it's segfaulting
on
CURRENT, considering also that AFAIK the gcc version in both the base
systems
is the same.
In the part of the code causing the crash, a std::map is read with an
iterator
in a for loop, and if a condition is met, an entry is erased.
The following is the bt I'm getting:
#0 0x29e36247 in kill () from /lib/libc.so.7
#1 0x29e361a6 in raise () from /lib/libc.so.7
#2 0x282424f6 in XRE_LockProfileDirectory () from
/usr/local/lib/firefox3/libxul.so
#3 signal handler called
#4 0x29c8f1b2 in std::_Rb_tree_increment () from
/usr/lib/libstdc++.so.6 #5 0x2ef92402 in
IcedTeaPluginUtilities::invalidateInstance () from
/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
...
I wrote a patch for the IcedTea plugin, replacing the for loop with a
while
and increasing the iterator before erasing from the map, and it seems
working.
Then I wrote a simple program that do something similar to IcedTea, so
there
is no need to build the whole java/openjdk6 port to do some testing.
Running it on 8_STABLE it works, on CURRENT it crashes.
You can find more details in this discussion on the freebsd-java ml:
http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
You can find the patch and the sample code in the discussion above, anyway
I'm
reporting them here too:
icedtea patch:
http://pastebin.com/b2KKFNSG
test case:
http://pastebin.com/Amk4UJ0g
You appear to invalidate the iterator inside the loop and then
increment it. Do the following:
-- cut here --
for (iter = cars.begin(); iter != cars.end(); ) {
if ((*iter).second == modelName)
cars.erase(iter++);
else
++iter;
}
-- and here --
In this example, you first increment the iterator and then erase its
previous value.
So there is a bug in my source code! Well, I'm not surprised.
I'm trying to report the code in icedtea here, extracting it from the patch so
I hope it's accurate enough:
std::mapvoid*,NPP::iterator iterator;
for (iterator = instance_map-begin(); iterator != instance_map-end();
iterator++)
{
if ((*iterator).second == instance)
{
instance_map-erase((*iterator).first);
}
}
So, do you think, like Ed Schouten said, that there is a bug in the source
code but it's just exposed on CURRENT?
Is that code bad too?
Thanks
Barbara
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:11 AM, Vlad Galu d...@dudu.ro wrote:
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
But maybe it's not a problem related to the port.
Just to be clear, I'm not looking for a solution about the port here, I'm
just
wondering why the same c++ code is working on 8_STABLE and it's segfaulting
on
CURRENT, considering also that AFAIK the gcc version in both the base systems
is the same.
In the part of the code causing the crash, a std::map is read with an
iterator
in a for loop, and if a condition is met, an entry is erased.
The following is the bt I'm getting:
#0 0x29e36247 in kill () from /lib/libc.so.7
#1 0x29e361a6 in raise () from /lib/libc.so.7
#2 0x282424f6 in XRE_LockProfileDirectory () from
/usr/local/lib/firefox3/libxul.so
#3 signal handler called
#4 0x29c8f1b2 in std::_Rb_tree_increment () from
/usr/lib/libstdc++.so.6 #5 0x2ef92402 in
IcedTeaPluginUtilities::invalidateInstance () from
/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
...
I wrote a patch for the IcedTea plugin, replacing the for loop with a while
and increasing the iterator before erasing from the map, and it seems
working.
Then I wrote a simple program that do something similar to IcedTea, so there
is no need to build the whole java/openjdk6 port to do some testing.
Running it on 8_STABLE it works, on CURRENT it crashes.
You can find more details in this discussion on the freebsd-java ml:
http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
You can find the patch and the sample code in the discussion above, anyway
I'm
reporting them here too:
icedtea patch:
http://pastebin.com/b2KKFNSG
test case:
http://pastebin.com/Amk4UJ0g
You appear to invalidate the iterator inside the loop and then
increment it. Do the following:
-- cut here --
for (iter = cars.begin(); iter != cars.end(); ) {
if ((*iter).second == modelName)
cars.erase(iter++);
else
++iter;
}
-- and here --
In this example, you first increment the iterator and then erase its
previous value.
Or, better yet: cars.erase(punto); I see no reason in iterating
through the whole map unless you want to relate the deletion to the
matched type, in which case you should use the previous example.
--
Good, fast cheap. Pick any two.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:31 AM, Barbara barbara.xxx1...@libero.it wrote:
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
But maybe it's not a problem related to the port.
Just to be clear, I'm not looking for a solution about the port here, I'm
just
wondering why the same c++ code is working on 8_STABLE and it's segfaulting
on
CURRENT, considering also that AFAIK the gcc version in both the base
systems
is the same.
In the part of the code causing the crash, a std::map is read with an
iterator
in a for loop, and if a condition is met, an entry is erased.
The following is the bt I'm getting:
#0 0x29e36247 in kill () from /lib/libc.so.7
#1 0x29e361a6 in raise () from /lib/libc.so.7
#2 0x282424f6 in XRE_LockProfileDirectory () from
/usr/local/lib/firefox3/libxul.so
#3 signal handler called
#4 0x29c8f1b2 in std::_Rb_tree_increment () from
/usr/lib/libstdc++.so.6 #5 0x2ef92402 in
IcedTeaPluginUtilities::invalidateInstance () from
/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
...
I wrote a patch for the IcedTea plugin, replacing the for loop with a
while
and increasing the iterator before erasing from the map, and it seems
working.
Then I wrote a simple program that do something similar to IcedTea, so
there
is no need to build the whole java/openjdk6 port to do some testing.
Running it on 8_STABLE it works, on CURRENT it crashes.
You can find more details in this discussion on the freebsd-java ml:
http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
You can find the patch and the sample code in the discussion above, anyway
I'm
reporting them here too:
icedtea patch:
http://pastebin.com/b2KKFNSG
test case:
http://pastebin.com/Amk4UJ0g
You appear to invalidate the iterator inside the loop and then
increment it. Do the following:
-- cut here --
for (iter = cars.begin(); iter != cars.end(); ) {
if ((*iter).second == modelName)
cars.erase(iter++);
else
++iter;
}
-- and here --
In this example, you first increment the iterator and then erase its
previous value.
So there is a bug in my source code! Well, I'm not surprised.
I'm trying to report the code in icedtea here, extracting it from the patch so
I hope it's accurate enough:
std::mapvoid*,NPP::iterator iterator;
for (iterator = instance_map-begin(); iterator != instance_map-end();
iterator++)
{
if ((*iterator).second == instance)
{
instance_map-erase((*iterator).first);
}
}
So, do you think, like Ed Schouten said, that there is a bug in the source
code but it's just exposed on CURRENT?
Is that code bad too?
Thanks
Barbara
Yes, I believe CURRENT's malloc zeroes out the memory upon deletion,
whereas STABLE doesn't. So in STABLE you get an old copy of the
invalidated iterator, hence it works.
--
Good, fast cheap. Pick any two.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:32 AM, Vlad Galu d...@dudu.ro wrote:
On Sat, Nov 6, 2010 at 11:11 AM, Vlad Galu d...@dudu.ro wrote:
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
But maybe it's not a problem related to the port.
Just to be clear, I'm not looking for a solution about the port here, I'm
just
wondering why the same c++ code is working on 8_STABLE and it's segfaulting
on
CURRENT, considering also that AFAIK the gcc version in both the base
systems
is the same.
In the part of the code causing the crash, a std::map is read with an
iterator
in a for loop, and if a condition is met, an entry is erased.
The following is the bt I'm getting:
#0 0x29e36247 in kill () from /lib/libc.so.7
#1 0x29e361a6 in raise () from /lib/libc.so.7
#2 0x282424f6 in XRE_LockProfileDirectory () from
/usr/local/lib/firefox3/libxul.so
#3 signal handler called
#4 0x29c8f1b2 in std::_Rb_tree_increment () from
/usr/lib/libstdc++.so.6 #5 0x2ef92402 in
IcedTeaPluginUtilities::invalidateInstance () from
/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
...
I wrote a patch for the IcedTea plugin, replacing the for loop with a
while
and increasing the iterator before erasing from the map, and it seems
working.
Then I wrote a simple program that do something similar to IcedTea, so there
is no need to build the whole java/openjdk6 port to do some testing.
Running it on 8_STABLE it works, on CURRENT it crashes.
You can find more details in this discussion on the freebsd-java ml:
http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
You can find the patch and the sample code in the discussion above, anyway
I'm
reporting them here too:
icedtea patch:
http://pastebin.com/b2KKFNSG
test case:
http://pastebin.com/Amk4UJ0g
You appear to invalidate the iterator inside the loop and then
increment it. Do the following:
-- cut here --
for (iter = cars.begin(); iter != cars.end(); ) {
if ((*iter).second == modelName)
cars.erase(iter++);
else
++iter;
}
-- and here --
In this example, you first increment the iterator and then erase its
previous value.
Or, better yet: cars.erase(punto); I see no reason in iterating
through the whole map unless you want to relate the deletion to the
matched type, in which case you should use the previous example.
Sorry, I meant mapped type.
--
Good, fast cheap. Pick any two.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
But maybe it's not a problem related to the port.
Just to be clear, I'm not looking for a solution about the port here, I'm just
wondering why the same c++ code is working on 8_STABLE and it's segfaulting on
CURRENT, considering also that AFAIK the gcc version in both the base systems
is the same.
In the part of the code causing the crash, a std::map is read with an iterator
in a for loop, and if a condition is met, an entry is erased.
The following is the bt I'm getting:
#0 0x29e36247 in kill () from /lib/libc.so.7
#1 0x29e361a6 in raise () from /lib/libc.so.7
#2 0x282424f6 in XRE_LockProfileDirectory () from
/usr/local/lib/firefox3/libxul.so
#3 signal handler called
#4 0x29c8f1b2 in std::_Rb_tree_increment () from
/usr/lib/libstdc++.so.6 #5 0x2ef92402 in
IcedTeaPluginUtilities::invalidateInstance () from
/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
...
I wrote a patch for the IcedTea plugin, replacing the for loop with a while
and increasing the iterator before erasing from the map, and it seems working.
Then I wrote a simple program that do something similar to IcedTea, so there
is no need to build the whole java/openjdk6 port to do some testing.
Running it on 8_STABLE it works, on CURRENT it crashes.
You can find more details in this discussion on the freebsd-java ml:
http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
You can find the patch and the sample code in the discussion above, anyway I'm
reporting them here too:
icedtea patch:
http://pastebin.com/b2KKFNSG
test case:
http://pastebin.com/Amk4UJ0g
You appear to invalidate the iterator inside the loop and then
increment it. Do the following:
-- cut here --
for (iter = cars.begin(); iter != cars.end(); ) {
if ((*iter).second == modelName)
cars.erase(iter++);
else
++iter;
}
-- and here --
In this example, you first increment the iterator and then erase its
previous value.
--
Good, fast cheap. Pick any two.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
R: Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:31 AM, Barbara barbara.xxx1...@libero.it wrote:
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
But maybe it's not a problem related to the port.
Just to be clear, I'm not looking for a solution about the port here, I'm
just
wondering why the same c++ code is working on 8_STABLE and it's
segfaulting
on
CURRENT, considering also that AFAIK the gcc version in both the base
systems
is the same.
In the part of the code causing the crash, a std::map is read with an
iterator
in a for loop, and if a condition is met, an entry is erased.
The following is the bt I'm getting:
#0 0x29e36247 in kill () from /lib/libc.so.7
#1 0x29e361a6 in raise () from /lib/libc.so.7
#2 0x282424f6 in XRE_LockProfileDirectory () from
/usr/local/lib/firefox3/libxul.so
#3 signal handler called
#4 0x29c8f1b2 in std::_Rb_tree_increment () from
/usr/lib/libstdc++.so.6 #5 0x2ef92402 in
IcedTeaPluginUtilities::invalidateInstance () from
/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
...
I wrote a patch for the IcedTea plugin, replacing the for loop with a
while
and increasing the iterator before erasing from the map, and it seems
working.
Then I wrote a simple program that do something similar to IcedTea, so
there
is no need to build the whole java/openjdk6 port to do some testing.
Running it on 8_STABLE it works, on CURRENT it crashes.
You can find more details in this discussion on the freebsd-java ml:
http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
You can find the patch and the sample code in the discussion above,
anyway
I'm
reporting them here too:
icedtea patch:
http://pastebin.com/b2KKFNSG
test case:
http://pastebin.com/Amk4UJ0g
You appear to invalidate the iterator inside the loop and then
increment it. Do the following:
-- cut here --
for (iter = cars.begin(); iter != cars.end(); ) {
if ((*iter).second == modelName)
cars.erase(iter++);
else
++iter;
}
-- and here --
In this example, you first increment the iterator and then erase its
previous value.
So there is a bug in my source code! Well, I'm not surprised.
I'm trying to report the code in icedtea here, extracting it from the patch
so
I hope it's accurate enough:
std::mapvoid*,NPP::iterator iterator;
for (iterator = instance_map-begin(); iterator != instance_map-end();
iterator++)
{
if ((*iterator).second == instance)
{
instance_map-erase((*iterator).first);
}
}
So, do you think, like Ed Schouten said, that there is a bug in the source
code but it's just exposed on CURRENT?
Is that code bad too?
Thanks
Barbara
Yes, I believe CURRENT's malloc zeroes out the memory upon deletion,
whereas STABLE doesn't. So in STABLE you get an old copy of the
invalidated iterator, hence it works.
Very nice explanation.
Thanks
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Re: libstc++ (?) problem on CURRENT?
On Sat, Nov 6, 2010 at 11:44 AM, Barbara barbara.xxx1...@libero.it wrote:
On Sat, Nov 6, 2010 at 11:31 AM, Barbara barbara.xxx1...@libero.it wrote:
On Sat, Nov 6, 2010 at 10:57 AM, Barbara barbara.xxx1...@libero.it wrote:
I had a problem running the IcedTea java plugin on CURRENT i386, while it
works on 8_STABLE.
But maybe it's not a problem related to the port.
Just to be clear, I'm not looking for a solution about the port here, I'm
just
wondering why the same c++ code is working on 8_STABLE and it's
segfaulting
on
CURRENT, considering also that AFAIK the gcc version in both the base
systems
is the same.
In the part of the code causing the crash, a std::map is read with an
iterator
in a for loop, and if a condition is met, an entry is erased.
The following is the bt I'm getting:
#0 0x29e36247 in kill () from /lib/libc.so.7
#1 0x29e361a6 in raise () from /lib/libc.so.7
#2 0x282424f6 in XRE_LockProfileDirectory () from
/usr/local/lib/firefox3/libxul.so
#3 signal handler called
#4 0x29c8f1b2 in std::_Rb_tree_increment () from
/usr/lib/libstdc++.so.6 #5 0x2ef92402 in
IcedTeaPluginUtilities::invalidateInstance () from
/usr/local/openjdk6/jre/lib/IcedTeaPlugin.so
...
I wrote a patch for the IcedTea plugin, replacing the for loop with a
while
and increasing the iterator before erasing from the map, and it seems
working.
Then I wrote a simple program that do something similar to IcedTea, so
there
is no need to build the whole java/openjdk6 port to do some testing.
Running it on 8_STABLE it works, on CURRENT it crashes.
You can find more details in this discussion on the freebsd-java ml:
http://lists.freebsd.org/pipermail/freebsd-java/2010-November/008978.html
You can find the patch and the sample code in the discussion above,
anyway
I'm
reporting them here too:
icedtea patch:
http://pastebin.com/b2KKFNSG
test case:
http://pastebin.com/Amk4UJ0g
You appear to invalidate the iterator inside the loop and then
increment it. Do the following:
-- cut here --
for (iter = cars.begin(); iter != cars.end(); ) {
if ((*iter).second == modelName)
cars.erase(iter++);
else
++iter;
}
-- and here --
In this example, you first increment the iterator and then erase its
previous value.
So there is a bug in my source code! Well, I'm not surprised.
I'm trying to report the code in icedtea here, extracting it from the patch
so
I hope it's accurate enough:
std::mapvoid*,NPP::iterator iterator;
for (iterator = instance_map-begin(); iterator != instance_map-end();
iterator++)
{
if ((*iterator).second == instance)
{
instance_map-erase((*iterator).first);
}
}
So, do you think, like Ed Schouten said, that there is a bug in the source
code but it's just exposed on CURRENT?
Is that code bad too?
Thanks
Barbara
Yes, I believe CURRENT's malloc zeroes out the memory upon deletion,
whereas STABLE doesn't. So in STABLE you get an old copy of the
invalidated iterator, hence it works.
Very nice explanation.
Thanks
I hope I'm right, I don't have CURRENT installed, it's just an
assumption. However, the C++ code is most definitely buggy.
--
Good, fast cheap. Pick any two.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
