On Friday, December 21, 2012 10:05:50 AM UTC+1, Nils Bruin wrote:
>
>
>
> On Dec 19, 12:16 am, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote:
> > Just when I thought the #715 + #11521 issues were fixed in
> sage-5.5.rc1...
> >
> > Apparently, sage-5.6.beta0 has uncovered a new problem: with the current
> > sage-5.6.beta0, I get the following reproducible segfault on hawk
> > (OpenSolaris i386):
> >
> > > sage -t --long -force_lib devel/sage/sage/modules/module.pyx
> > > The doctested process was killed by signal 11
> > > [24.3 s]
> I tried this on linux too:
> 1) I built 5.6b0 and tried the test: success
> 2) I set MALLOC_CHECK_=3. BOOM. Similar error as reported
> Now comes the odd part:
> If I turn off MALLOC_CHECK_ it now ALSO goes BOOM.
> If I run with --verbose tests complete without problem
> If I run with valgrind it STILL Segfaults (and I do get a mildly
> informative report about
> python's obmalloc.c:788, i.e.,
> if ((pool->freeblock = *(block **)bp) != NULL) {
> doing a read from an unallocated address)
>
> Note that the segfault happens somewhere deep inside Python's import
> machinery. My guess is something got corrupted (and written to a pyc
> file?) and now spoils the fun every time.
>
> Anyway, perhaps someone can replicate that this test fails on linux
> with MALLOC_CHECK_=3 as well. Possibly valgrinding finds a useful
> report.
>
I get segfaults on Ubuntu 12.04.1 x86_64 even without MALLOC_CHECK_ but not
every time.
The Valgrind output is not that informative, it dies with a SIGILL in
visit_decref (gcmodule.c: 320) where it jumps to a very fishy address.
If I use verbose I could not reproduce it.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
