|
|
On Thu, 2008-05-22 at 08:12 -1000, David Cantrell wrote:
On May 22, 2008, at 7:56 AM, Matt Rose wrote: > As part of an anaconda install, I'm running jetty, and feeding data > into a postgresql database through jetty using another java > program. (Don't ask why we're doing this. That way lies madness) > This command works fine outside of anaconda, but when I try it as > part of the CD installation using anaconda, Java crashes with sig11 > on the same malloc and memset call each time. *blink* _What_ are you doing again?
Yeah, as I said, don't ask. Basically we're loading xml data into a postgresql database, using java and jdbc. I keep telling people that it's way outside of the design of anaconda, but, as the buggy whip maker said to candlestick maker, "It used to work"
> >From my rudimentary C programming, a signal 11 is caused by reading > unassigned RAM, or RAM that's somehow faulty. Given that this > problem seems to only occur in anaconda, what in anaconda could be > causing java to try to access this memory address that causes it to > crash? http://www.bitwizard.nl/sig11/
Oddly enough, that's one of the pages I was reading just before I sent this email. That deals with random sig11 errors, usually caused by weird hardware. It's a page I use as a pointer tool all the time.
The interesting part of this error message is that it's always the same malloc call that fails. I would normally chalk it up to java, but this same java code runs fine outside of anaconda. I might try and come up with a pure C reproduction case, but it seems easier to work around the problem.
> If it helps, I'm using anaconda-11.2.87 We never released a version 11.2.87. Are you sure it came from us?
Sorry, real version is anaconda-11.1.2.87, actually, the CentOS version, to which I have to submit a patch because I've put a few fixes in there. Most of which have been superseded by the patches you put to the list a few months ago.
> Stack: [0x90538000,0x905b9000], sp=0x905b6d54, free space=507k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > C [libc.so.6+0x6e077] memset+0x37 > C [libc.so.6+0x6812e] __libc_malloc+0x7e > V [libjvm.so+0x4f7c4a] > V [libjvm.so+0x198705] > V [libjvm.so+0x198c26] > V [libjvm.so+0x344492] > V [libjvm.so+0x255f58] > V [libjvm.so+0x2a29ad] > V [libjvm.so+0x29f830] > V [libjvm.so+0x247149] > V [libjvm.so+0x2a6d1a] > V [libjvm.so+0x2a6726] > V [libjvm.so+0x5b5d7d] > V [libjvm.so+0x4fde19] > C [libpthread.so.0+0x543b] I can speak for myself and possibly the rest of the team: I have no Java knowledge. Java to me is sort of like Agent Smith combined with a velociraptor. Sure, it has great diction and professional looking clothes, but what it really wants to do is rip open your belly and watch your insides spill out on to the floor.
I hear you. I have some java knowledge, but I'm the python/perl/shell/rpm/ruby/C guy at a company that mainly uses Java, and C#.
There are far too many variables in this problem to even suggest at what could be going wrong. This isn't really a support list, this is the development discussion list. If you are modifying anaconda for another product, we can usually answer questions about what this file does, what that class does, and so on. Sometimes we do, sometimes we don't. It really depends on the mood of the reader, the alignment of the planets, and other such factors.
I wasn't really expecting that much help, other than, maybe it was a known bug that was fixed in version x. I have a long painful workaround to implement now, I guess.
Thanks again for your time. Maybe somebody else on the list has some ideas...
Matt
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
