[gentoo-amd64] Re: bug report help

[Duncan]

Fernando Boaglio posted on Mon, 24 Jan 2011 13:41:59 -0200 as excerpted:

> I did, same thing:
>
>
> fb@de09 ~/eclipse $ ./eclipse -vm /opt/icedtea6-bin-1.9.4/bin/java
> -vmargs -Xms1024M -Xmx1024M -XX:PermSize=256M -XX:MaxPermSize=256M
> -XX:+UseSerialGC
>
>
> *** glibc detected *** /opt/icedtea6-bin-1.9.4/bin/java: free(): invalid
> pointer: 0x00000000033244c0 ***

Two notes, here:

1) I don't know about sunjdk as there's license issues such that I won't 
install it, but the iced-tea6-bin package, while free, is a pre-compiled 
binary install.  As such, revdep-rebuild won't be able to do anything for 
it as it'll just reinstall the same binary, so the package installs a 
revdep-rebuild control file so revdep-rebuild skips checking it, to 
prevent reinstalls that wouldn't fix anything.

FWIW there's the icedtea package for from-source building, but the build-
process is said to be quite convoluted, many dependencies, etc., thus the 
binary package option.

If the sunjdk package similarly has binary components, since that's what 
originally triggered the bug, that /might/ be your issue.  However, I 
don't know that it does.

2) What version of glibc do you have?  Unless you're running ~arch or even 
masked/live, this probably doesn't apply, but... LWN article posted Nov 
10, 2010 about a glibc change to memcpy behavior when used in a context 
with specifically undefined behavior:

http://lwn.net/Articles/414467/

Also see the Nov 24, 2010 longer LWN commentary article, which covers both 
the glibc change and a kernel behavior change, examining how they were 
handled when found to break things, etc.

http://lwn.net/Articles/416821/

FWIW, I'm with the glibc folks here.  The behavior is specifically said to 
be undefined when the memory regions overlap, and think about it, if your 
memory source and destination regions overlap, by definition it's not a 
simple copy anyway, as the data in the source region has changed at the 
end and with a simple copy, it should intuitively be the same as it was -- 
unless you overlap the copies, but then that's not a simple copy so 
shouldn't be using the copy function!  Duh!

The kernel thing is specifically different, in part because Linus has 
established clear rules about breaking the kernel/userspace interface (in 
a word, don't!) -- part of the reason that change was reverted.  If it had 
instead been specifically documented as changeable, much like the kernel's 
internal interfaces are (much to the dismay of many closed-source kernel 
module devs)... the outcome there would likely have been similar to the 
glibc outcome.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman