On Wed, Jan 30, 2013 at 4:32 PM, PhilipNienhuis wrote:
>
> Julien Bect wrote
>>
>> Jordi Gutiérrez Hermoso-2 wrote
>>> On 30 January 2013 09:19, Julien Bect <
>
>>> julien.bect@
>
>>> > wrote:
>>>> Note that I haven't been able to run a full "make check", though (it
>>>> segfaults when I reach the tests for dblquad.m, but this is not
>>>> related to my patch).
>>>
>>> Is this a known problem? Should we diagnose it?
>>>
>>> - Jordi G. H.
>> Yes it is known:
>> https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-December/031324.html
>>
>> I get this on both of my dev boxes (an old Pentium M laptop and a
>> middle-aged Intel Core Duo) both with Mageia 2.
>>
>> More or less based on the various Java-related segfault bug reports (where
>> Java actually seems unrelated) I didn't pursue much further as I'm unable
>> to debug this and I figured (hoped) it would be picked up at some point.
>> [...]
> Build ended OK
>
> address@hidden octave]$ hg summary
> parent: 15972:22ab4fe661d7 tip
>
> After installation and running:
> gdb octave
> :
> bt
>
> I got essentially the same results as in earlier post (only the memory
> addresses differed a little, but stack trace still 242 deep).
Similar here, fresh build on 32-bit Debian with gcc 4.7.2. I stand
corrected about only seeing it with older gcc versions, but still only
on 32-bit builds.
I agree Java is interacting with something or consuming resources to
make dblquad fail. This works:
$ ./run-octave -qf --eval 'test dblquad'
PASSES 4 out of 4 tests
This doesn't:
$ ./run-octave -qf --eval 'o = javaObject ("java.lang.Object"); test dblquad'
Segmentation fault
Does your build have jit enabled? If yes, can you try without it?
Michael.