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
