libsingular problems with ring deallocation

[Nils Bruin]

Dear (lib)singular experts,

Sage ticket http://trac.sagemath.org/sage_trac/ticket/13447 describes
a problem that may or may not be specific to MacOSX 10.6 x86_64 (or
even just bsd.math.washington.edu). With recent work of Simon King,
parents have become more likely to be collected and this is causing a
problem in a specific doctest on bsd.math.washington.edu: a segfault
in a doctest. The segfault itself is rather sensitive to the order of
execution, but is otherwise reliably reproduced.

We tracked it down to an omAlloc call for <= 8 byte blocks
segfaulting, which basically must mean a freelist corruption (either
by writing-after-freeing or by writing out-of-bounds). There must be
omAlloc debugging wizards here who can quickly identify and fix the
problem. You'd help sage a lot by finally allowing
MPolynomialRing_libsingular to join the mortal world.

Nils

[Simon King]

Hi (lib)singular experts,

Am Dienstag, 11. September 2012 18:15:43 UTC+2 schrieb Nils Bruin:

Sage ticket http://trac.sagemath.org/sage_trac/ticket/13447 describes
a problem that may or may not be specific to MacOSX 10.6 x86_64 (or
even just bsd.math.washington.edu).

Meanwhile Nils has created ticket http://trac.sagemath.org/sage_trac/ticket/13731, which aims at the creation of a singular spkg that uses malloc rather than omalloc: In that way, segfaults are better reproducible and are easier to analyse with gdb and valgrind.

In fact, Nils has already found several upstream bugs (see http://www.singular.uni-kl.de:8002/trac/ticket/463).

We do not intend to make malloc-Singular spkg the default (in fact, the malloc-Singular spkg does not even produce a working executable), but it would be nice if it would build both on linux and on osx. Problem: This would require to change some configure scripts.

Question to people who are familiar with the Singular spkg in Sage: The spkg contains the file src/omalloc/configure, which is autogenerated -- hence, I am surprised it is there, because I thought that an spkg should only contain the sources, not the files that are generated from the sources.

When I edit src/omalloc/configure.in, my changes are ignored when building the spkg, and thus it doesn't build on osx. However, when I delete src/omalloc/configure, then it will *not* be created by autoconf, and so building the spkg fails again.

Do you have a hint how I can make the spkg build with a modified configuration?

Best regards,
Simon

[han...@mathematik.uni-kl.de]

On Mon, Nov 26, 2012 at 05:30:49AM -0800, Simon King wrote:
....

>
> We do not intend to make malloc-Singular spkg the default (in fact, the
> malloc-Singular spkg does not even produce a working executable), but it
> would be nice if it would build both on linux and on osx. Problem: This
> would require to change some configure scripts.

A much better way instead of changing omalloc would be to use xalloc
which is a compatibility layer for omalloc on top of malloc
(see
https://github.com/Singular/Sources/tree/spielwiese/xalloc
)

>
> Question to people who are familiar with the Singular spkg in Sage: The
> spkg contains the file src/omalloc/configure, which is autogenerated --
> hence, I am surprised it is there, because I thought that an spkg should
> only contain the sources, not the files that are generated from the sources.
>
> When I edit src/omalloc/configure.in, my changes are ignored when building
> the spkg, and thus it doesn't build on osx. However, when I delete
> src/omalloc/configure, then it will *not* be created by autoconf, and so
> building the spkg fails again.

That a problem of chicken-egg-kind: If you have a Makefile,
it could recreate configure from configure.in.
But for Makefile, one need to run configure first.
So Singular packages contain both configure and configure.in.
Another problem is the dependency on the correct autoconf version:
autoconf changed quite it bit over the version and is quite bad in
handling input intended for other versions.

>
> Do you have a hint how I can make the spkg build with a modified
> configuration?

Simply generate configure and add both configure and configure.in to the
source package.
>
> Best regards,
> Simon
>
Hannes

[Volker Braun]

On Monday, November 26, 2012 1:30:49 PM UTC, Simon King wrote:

Question to people who are familiar with the Singular spkg in Sage: The spkg contains the file src/omalloc/configure, which is autogenerated -- hence, I am surprised it is there, because I thought that an spkg should only contain the sources, not the files that are generated from the sources.

In autotools, the only file that you should edit manually is configure.ac (or configure.in, but that is deprecated). Then autoconf takes configure.ac and generates configure. Since Sage does not require autotools, every spkg must ship with the autoconf output. Usually, upstream distributes the autogenerated configure script since it might depend on the precise autotools version (and so that ./configure && make && make install works)

[Simon King]

Hi Volker,

Am Montag, 26. November 2012 15:23:13 UTC+1 schrieb Volker Braun:

In autotools, the only file that you should edit manually is configure.ac (or configure.in, but that is deprecated).

There is only one configure.ac in the Singular spkg, namely gfanlib/configure.ac ...
 

Since Sage does not require autotools, every spkg must ship with the autoconf output.

Aha! So, changing the configure script in an spkg seems not to be deprecated, then?

[Simon King]

Am Montag, 26. November 2012 15:00:48 UTC+1 schrieb han...@mathematik.uni-kl.de:

....

A much better way instead of changing omalloc would be to use xalloc
which is a compatibility layer for omalloc on top of malloc
(see
https://github.com/Singular/Sources/tree/spielwiese/xalloc
)

How to use it? The README file is empty.

In particular, how to use it in Singular-3-1-5? If I am not mistaken, there is no Spielwiese spkg.

Best regards,
Simon

[han...@mathematik.uni-kl.de]

That is nor needed: works also with singulars master branch.
>
> Best regards,
> Simon
>
rename omalloc directory to omalloc.org,
rename xalloc to omalloc
edit omalloc/Makefile (for the correct path names)
make install
compile the rest of Singular or libsinsgular

Hannes

[Simon King]

Hi Hannes,

Am Montag, 26. November 2012 16:13:27 UTC+1 schrieb han...@mathematik.uni-kl.de:

rename omalloc directory to omalloc.org,
rename xalloc to omalloc

Would deleting the old content of omalloc/ and dropping the content of xalloc into omalloc/ work, or is it essential that the old content of omalloc is still around under the new name? "org" is not mentioned in the xalloc sources, if I am not mistaken.
 

edit omalloc/Makefile (for the correct path names)

Do you refer to the old omalloc/Makefile.in, that will be moved to omalloc.org/Makefile.in? Or do you refer to xomalloc/Makefile.ac, that will be moved to omalloc/Makefile.ac?
 

make install
compile the rest of Singular or libsinsgular

 Or, for creating an spkg, it probably means to run autoconf on xalloc/configure.ac and copy the resulting configure script into the spkg as well, right?

Best regards,
Simon

[Volker Braun]

On Monday, November 26, 2012 2:43:38 PM UTC, Simon King wrote:

In autotools, the only file that you should edit manually is configure.ac (or configure.in, but that is deprecated).

There is only one configure.ac in the Singular spkg, namely gfanlib/configure.ac ...

configure.in is just the old (and deprecated) name for configure.ac

Aha! So, changing the configure script in an spkg seems not to be deprecated, then?

You can patch configure, if that is what you mean. Its very brittle and will break whenever upstream updates their autotools, of course. We don't have a good system in place when upstream uses ancient/buggy/not functional enough versions of autotools and everything needs to be regenerated. 

 

[han...@mathematik.uni-kl.de]

On Mon, Nov 26, 2012 at 07:34:25AM -0800, Simon King wrote:
> Hi Hannes,
>
> Am Montag, 26. November 2012 16:13:27 UTC+1 schrieb
> han...@mathematik.uni-kl.de:
> >
> > rename omalloc directory to omalloc.org,
> > rename xalloc to omalloc
> >
>
> Would deleting the old content of omalloc/ and dropping the content of
> xalloc into omalloc/ work, or is it essential that the old content of
> omalloc is still around under the new name? "org" is not mentioned in the
> xalloc sources, if I am not mistaken.
>

Yes, you can delete the original omalloc.

>
> > edit omalloc/Makefile (for the correct path names)
> >
>
> Do you refer to the old omalloc/Makefile.in, that will be moved to
> omalloc.org/Makefile.in? Or do you refer to xomalloc/Makefile.ac, that will
> be moved to omalloc/Makefile.ac?

no, there is a configure.ac in the (now named) omalloc directory.
From that one can generate (with autoconf) configure,
which needs be get the right pathnames (either by editing a generated
Makefile or by passing the right arguments from the
top-level-configure).

>
>
> > make install
> > compile the rest of Singular or libsinsgular
> >
>
> Or, for creating an spkg, it probably means to run autoconf on
> xalloc/configure.ac and copy the resulting configure script into the spkg
> as well, right?

yes, and make sure that the top level configure calls it with the right
path names.
>
> Best regards,
> Simon
>
Hannes.

[Simon King]

Hi Hannes,

Zitat von han...@mathematik.uni-kl.de:

> Yes, you can delete the original omalloc.

Thank you! A little destruction from time to time makes life easier.

> no, there is a configure.ac in the (now named) omalloc directory.
> From that one can generate (with autoconf) configure,
> which needs be get the right pathnames (either by editing a generated
> Makefile or by passing the right arguments from the
> top-level-configure).

I'll try that later. But one more question: Is it needed to give
--with-emulate-omalloc to ./configure?

Best regards,
Simon



----------------------------------------------------------------
This message was sent through https://webmail.uni-jena.de

[han...@mathematik.uni-kl.de]

On Mon, Nov 26, 2012 at 05:18:16PM +0100, Simon King wrote:
> Hi Hannes,
>
> Zitat von han...@mathematik.uni-kl.de:
> > Yes, you can delete the original omalloc.
>
> Thank you! A little destruction from time to time makes life easier.
>
> > no, there is a configure.ac in the (now named) omalloc directory.
> > From that one can generate (with autoconf) configure,
> > which needs be get the right pathnames (either by editing a generated
> > Makefile or by passing the right arguments from the
> > top-level-configure).
>
> I'll try that later. But one more question: Is it needed to give
> --with-emulate-omalloc to ./configure?

no, this is implicit given by using xalloc.

Hannes

[Simon King]

Hi!

Sorry for asking stupid questions, but I have no experience whatsoever with autoconf and friends, and so far I have only seen documentation on how to write configure.ac, but I did not find a tutorial on using auto* to produce configure script and Makefile.

Am Montag, 26. November 2012 17:01:25 UTC+1 schrieb han...@mathematik.uni-kl.de:

no, there is a configure.ac in the (now named) omalloc directory.
From that one can generate (with autoconf) configure,

Running "autoconf" in the xalloc/ folder results in some warning about potentially undefined stuff.

By mere coincidence, I found that I should first run "aclocal". Then, running "autoconf" again worked, this time without warning.

Next, in order to create a Makefile, I ran "automake". There were many warnings about missing required files, suggesting that I should run "automake --add-missing". It did install some things, but it could not find ltmain.sh. By consequence, when I ran "automake" again, no Makefile was created.

That boils down to two questions:
 * Where do I get ltmain.sh from?
 * When I create an spkg, does it suffice to copy the auto-generated configure and Makefile into the spkg's src/ folder, or should I also copy the scripts found by "automake --add-missing"?
 

which needs be get the right pathnames (either by editing a generated
Makefile or by passing the right arguments from the
top-level-configure).

 
How do I pass arguments from the top-level-configure?

Best regards,
Simon

[Simon King]

Hi!

Am Montag, 26. November 2012 21:19:22 UTC+1 schrieb Simon King:

That boils down to two questions:
 * Where do I get ltmain.sh from?

Meanwhile I found it, copied it into the folder, ran "automake" again, and thus have Makefile.in.

 

 * When I create an spkg, does it suffice to copy the auto-generated configure and Makefile into the spkg's src/ folder, or should I also copy the scripts found by "automake --add-missing"?

This I don't know yet.
 

which needs be get the right pathnames (either by editing a generated
Makefile or by passing the right arguments from the
top-level-configure).

 
How do I pass arguments from the top-level-configure?

In Makefile.in, I do not find any strange path names. Hence, I'll simply try whether copying "configure" and "Makefile.in" into the spkg will be enough.

Best regards,
Simon

[Simon King]

Hi!

Meanwhile a different problem arose.

Am Dienstag, 27. November 2012 10:34:26 UTC+1 schrieb Simon King:

 * When I create an spkg, does it suffice to copy the auto-generated configure and Makefile into the spkg's src/ folder, or should I also copy the scripts found by "automake --add-missing"?

This I don't know yet.

Now I know. It *is* needed.
 

which needs be get the right pathnames (either by editing a generated
Makefile or by passing the right arguments from the
top-level-configure).

 
How do I pass arguments from the top-level-configure?

Still don't know.
 
When I try to build it, it turns out that make is called with a target that is not recognized by the Makefile created with auto*:

make install-nolns in omalloc
make[1]: Entering directory `/home/simon/SAGE/debug/sage-5.5.rc0/spkg/build/singular-3-1-5.p2/src/omalloc'
make[1]: *** Keine Regel, um »install-nolns« zu erstellen.  Schluss.
make[1]: Leaving directory `/home/simon/SAGE/debug/sage-5.5.rc0/spkg/build/singular-3-1-5.p2/src/omalloc'
make: *** [install-nolns] Fehler 1

Do you have an idea how to get the target "install-nolns" into the Makefile?
I guess I'd need to patch xalloc/Makefile.am before repeating "automake". But how do I need to patch it?

Best regards,
Simon

[han...@mathematik.uni-kl.de]

On Tue, Nov 27, 2012 at 03:35:23AM -0800, Simon King wrote:
>
> make install-nolns in omalloc
> make[1]: Entering directory
> `/home/simon/SAGE/debug/sage-5.5.rc0/spkg/build/singular-3-1-5.p2/src/omalloc'
> make[1]: *** Keine Regel, um �install-nolns� zu erstellen. Schluss.
> make[1]: Leaving directory
> `/home/simon/SAGE/debug/sage-5.5.rc0/spkg/build/singular-3-1-5.p2/src/omalloc'
> make: *** [install-nolns] Fehler 1
>
> Do you have an idea how to get the target "install-nolns" into the Makefile?
> I guess I'd need to patch xalloc/Makefile.am before repeating "automake".
> But how do I need to patch it?
>
> Best regards,
> Simon
>

You need to add to Makefile.am:

lib_LIBRARIES=libomalloc.a

(for example after
lib_LTLIBRARIES=libomalloc.la ${LIB_G}
)

and later to Makefile (for example at the end)
(do not know how to add this to Makefile.am)

install-nolns: install

Hans

[Simon King]

Dear Hannes,

Am Dienstag, 27. November 2012 14:04:28 UTC+1 schrieb han...@mathematik.uni-kl.de:

You need to add to Makefile.am:
 
lib_LIBRARIES=libomalloc.a

(for example after
 lib_LTLIBRARIES=libomalloc.la ${LIB_G}
)
 
and later to Makefile (for example at the end)
(do not know how to add this to Makefile.am)

install-nolns: install

I am afraid this yields a strange error:

make install-nolns in omalloc
make[1]: Entering directory `/home/simon/SAGE/debug/sage-5.5.rc0/spkg/build/singular-3-1-5.p2/src/omalloc'

make[1]: *** Keine Regel vorhanden, um das Target »libomalloc.c«,
  benötigt von »libomalloc.o«, zu erstellen.  Schluss.

Why does it try to find libomalloc.c? For the record, after changing Makefile.am as you told me, I ran autoconf and automake again, and then edited Makefile.in as you told me.

By the way, the original advice was to empty the omalloc/ folder and put the content of the xalloc folder into it. By consequence, there is only a single .c file in omalloc/, namely dummy.c. Is that what it should be? Or should I keep some of the old c files?

Best regards,
Simon

[han...@mathematik.uni-kl.de]

On Tue, Nov 27, 2012 at 07:07:28AM -0800, Simon King wrote:
> Dear Hannes,

>
> By the way, the original advice was to empty the omalloc/ folder and put
> the content of the xalloc folder into it. By consequence, there is only a
> single .c file in omalloc/, namely dummy.c. Is that what it should be? Or
> should I keep some of the old c files?
>
> Best regards,
> Simon
>

Sorry, there are too many chnages for the spielwiese branch.
You better start again with
http://www.mathematik.uni-kl.de/~hannes/xalloc.tar.gz
which contains
-rw-r----- hannes/110 6731 2010-08-17 14:10 omalloc.h
-rwxr-x--x hannes/110 4730 2010-08-17 14:03 omFindExec.c
-rw-r----- hannes/110 863 2010-08-17 14:15 Makefile

which simply produces:
all: libomalloc_ndebug.a
The Makefile has needs additional an install target (resp.
install-nolns), which copies omalloc.h and libomalloc_ndebug.a
(probably as libomalloc.a) to the right places.

Hannes

[Simon King]

Dear Hannes,

Zitat von han...@mathematik.uni-kl.de:

> Sorry, there are too many chnages for the spielwiese branch.
> You better start again with
> http://www.mathematik.uni-kl.de/~hannes/xalloc.tar.gz

Thank you, that almost worked (i.e., it came past the point where
libomalloc.a was built).

Now, the error is
In file included from bigintmat.cc:8:0:
../kernel/febase.h:29:30: fatal error: omalloc/mylimits.h: Datei oder
Verzeichnis nicht gefunden
compilation terminated.

Where do I get mylimits.h from? Since it is called *my*limits.h, I
guess they are created by some configuration - hence, do I need some
configure script as well?

Cheers,

[han...@mathematik.uni-kl.de]

On Tue, Nov 27, 2012 at 10:16:40PM +0100, Simon King wrote:
> Dear Hannes,
>
> Zitat von han...@mathematik.uni-kl.de:
> > Sorry, there are too many chnages for the spielwiese branch.
> > You better start again with
> > http://www.mathematik.uni-kl.de/~hannes/xalloc.tar.gz
>
> Thank you, that almost worked (i.e., it came past the point where
> libomalloc.a was built).
>
> Now, the error is
> In file included from bigintmat.cc:8:0:
> ../kernel/febase.h:29:30: fatal error: omalloc/mylimits.h: Datei oder
> Verzeichnis nicht gefunden
> compilation terminated.
>
> Where do I get mylimits.h from? Since it is called *my*limits.h, I
> guess they are created by some configuration - hence, do I need some
> configure script as well?
>
> Cheers,
> Simon
>

Either copy it from the original omalloc
or substitute it by a file which contains only the following line:
#include <limits.h>

Hannes

[Simon King]

Dear Hannes,

Zitat von han...@mathematik.uni-kl.de:

>> Where do I get mylimits.h from? ...

>>
> Either copy it from the original omalloc
> or substitute it by a file which contains only the following line:
> #include <limits.h>

Thank you, that's yet another progress. The error now changed to the
following:

pDebug.cc: In function ‘BOOLEAN _p_Test(poly, ring, int)’:
pDebug.cc:214:3: error: ‘omError_NoError’ was not declared in this scope
pDebug.cc:223:5: error: ‘omTestList’ was not declared in this scope
pDebug.cc:223:5: error: ‘omError_NoError’ was not declared in this scope
pDebug.cc:234:5: error: ‘omError_NoError’ was not declared in this scope
make[1]: *** [pDebug.og] Fehler 1
make[1]: Leaving directory
`/home/simon/SAGE/debug/sage-5.5.rc0/spkg/build/singular-3-1-5.p2/src/kernel'

make: *** [install-nolns] Fehler 1

omTestList used to be defined in omalloc/omList.h, in Spielwiese it is
additionally defined in omalloc/omalloc.h.

omError_NoError used to be defined in omalloc/omError.h, in Spielwiese
it is additionally defined in xalloc/omalloc.h

Shall I perhaps simply copy these definitions into the new omalloc.h
that you gave me?

[Simon King]

Zitat von Simon King <simon...@uni-jena.de>:

> omTestList used to be defined in omalloc/omList.h, in Spielwiese it
> is additionally defined in omalloc/omalloc.h.
>
> omError_NoError used to be defined in omalloc/omError.h, in
> Spielwiese it is additionally defined in xalloc/omalloc.h
>
> Shall I perhaps simply copy these definitions into the new omalloc.h
> that you gave me?

No, I guess that won't work. omTestList eventually refers to
_omCheckList, defined in omList.c.

Best regards,

[han...@mathematik.uni-kl.de]

On Wed, Nov 28, 2012 at 10:49:58AM +0100, Simon King wrote:
> Zitat von Simon King <simon...@uni-jena.de>:
> > omTestList used to be defined in omalloc/omList.h, in Spielwiese it
> > is additionally defined in omalloc/omalloc.h.
> >
> > omError_NoError used to be defined in omalloc/omError.h, in
> > Spielwiese it is additionally defined in xalloc/omalloc.h
> >
> > Shall I perhaps simply copy these definitions into the new omalloc.h
> > that you gave me?
>
> No, I guess that won't work. omTestList eventually refers to
> _omCheckList, defined in omList.c.
>
> Best regards,
> Simon
>

As xalloc does not contain the debug stuff of omalloc, all that stuff
are dummies: just add the following to omalloc.h

enum omError_e
{
omError_NoError = 0,
omError_Unknown
};
#define omTestList(ptr, level) (omError_NoError)

Hannes

[Simon King]

Dear Hannes,

Zitat von han...@mathematik.uni-kl.de:

> enum omError_e
> {
> omError_NoError = 0,
> omError_Unknown
> };
> #define omTestList(ptr, level) (omError_NoError)

Then compilation of pDebug.cc complains in line 214 (and 234 as well),
which is
{{{
pPolyAssumeReturnMsg(omTestBinAddrSize(p,
(r->PolyBin->sizeW)*SIZEOF_LONG, level+1)
== omError_NoError, "memory error",p,r);
}}}

omTestBinAddrSize has been turned into macro and yields 0:
#define omTestBinAddrSize(A,B,C) ((void) 0)

omError_NoError should be 0 as well, according to your definition above.

But the error is
pDebug.cc:214:3: error: no match for ‘operator==’ in ‘0 == (omError_e)0u’

What next?

I tried to define
#define omTestBinAddrSize(A,B,C) ((void) omError_NoError)
but that didn't work.

[han...@mathematik.uni-kl.de]

On Wed, Nov 28, 2012 at 03:11:38PM +0100, Simon King wrote:
> Then compilation of pDebug.cc complains in line 214 (and 234 as well),
> which is
> {{{
> pPolyAssumeReturnMsg(omTestBinAddrSize(p,
> (r->PolyBin->sizeW)*SIZEOF_LONG, level+1)
> == omError_NoError, "memory error",p,r);
> }}}
>
> omTestBinAddrSize has been turned into macro and yields 0:
> #define omTestBinAddrSize(A,B,C) ((void) 0)

change it to
#define omTestBinAddrSize(A,B,C) (omError_NoError)

> I tried to define
> #define omTestBinAddrSize(A,B,C) ((void) omError_NoError)
> but that didn't work.

The return value is nedded: without "void"

Hans

[Simon King]

Dear Hannes,

Zitat von han...@mathematik.uni-kl.de:

>> omTestBinAddrSize has been turned into macro and yields 0:
>> #define omTestBinAddrSize(A,B,C) ((void) 0)
> change it to
> #define omTestBinAddrSize(A,B,C) (omError_NoError)

Thank you, that's another progress!

Now the error is
pDebug.cc: In function ‘BOOLEAN p_LmCheckIsFromRing(poly, ring)’:
pDebug.cc:91:7: error: base operand of ‘->’ is not a pointer
pDebug.cc: In function ‘BOOLEAN p_CheckPolyRing(poly, ring)’:
pDebug.cc:111:3: warning: NULL used in arithmetic [-Wpointer-arith]
pDebug.cc: In function ‘BOOLEAN p_LmCheckPolyRing(poly, ring)’:
pDebug.cc:117:3: warning: NULL used in arithmetic [-Wpointer-arith]
pDebug.cc: In function ‘BOOLEAN p_CheckRing(ring)’:
pDebug.cc:123:3: warning: NULL used in arithmetic [-Wpointer-arith]

make[1]: *** [pDebug.og] Fehler 1

That's a bit strange to me. Line 91 of pDebug.cc is
{{{
pPolyAssumeReturn(omIsBinPageAddr(p) &&
omSizeWOfAddr(p)==r->PolyBin->sizeW,p,r);
}}}
Context:

* r is of type "ring".
* #define omSizeWOfAddr(P) (omSizeOfAddr(P)/sizeof(long))
*
static inline long omSizeOfAddr(void *d)
{ long *dd=(long*)d; dd--; return *dd;}
* #define omIsBinPageAddr(A) ((void) 0)

Cheers,

[han...@mathematik.uni-kl.de]

On Wed, Nov 28, 2012 at 04:36:57PM +0100, Simon King wrote:
> Now the error is
> pDebug.cc: In function ‘BOOLEAN p_LmCheckIsFromRing(poly, ring)’:
> pDebug.cc:91:7: error: base operand of ‘->’ is not a pointer
> pDebug.cc: In function ‘BOOLEAN p_CheckPolyRing(poly, ring)’:
> pDebug.cc:111:3: warning: NULL used in arithmetic [-Wpointer-arith]
> pDebug.cc: In function ‘BOOLEAN p_LmCheckPolyRing(poly, ring)’:
> pDebug.cc:117:3: warning: NULL used in arithmetic [-Wpointer-arith]
> pDebug.cc: In function ‘BOOLEAN p_CheckRing(ring)’:
> pDebug.cc:123:3: warning: NULL used in arithmetic [-Wpointer-arith]
> make[1]: *** [pDebug.og] Fehler 1
>
> That's a bit strange to me. Line 91 of pDebug.cc is
> {{{
> pPolyAssumeReturn(omIsBinPageAddr(p) &&
> omSizeWOfAddr(p)==r->PolyBin->sizeW,p,r);
> }}}

The problem is PolyBin, which not really exists with xalloc.
So one should comment out all lines where PolyBin is derefenced:
--- kernel/pDebug.cc (Revision 15447)
+++ kernel/pDebug.cc (Arbeitskopie)
@@ -87,40 +87,50 @@
}
else
#endif
+ #ifndef X_OMALLOC

{
pPolyAssumeReturn(omIsBinPageAddr(p) && omSizeWOfAddr(p)==r->PolyBin->sizeW,p,r);

return TRUE;
}
return FALSE;
+ #endif
}
return TRUE;
}

BOOLEAN p_CheckIsFromRing(poly p, ring r)
{
+ #ifndef X_OMALLOC
while (p!=NULL)
{
pFalseReturn(p_LmCheckIsFromRing(p, r));
pIter(p);
}
+ #endif
return TRUE;
}

BOOLEAN p_CheckPolyRing(poly p, ring r)
{
+ #ifndef X_OMALLOC
pAssumeReturn(r != NULL && r->PolyBin != NULL);
+ #endif
return p_CheckIsFromRing(p, r);
}

BOOLEAN p_LmCheckPolyRing(poly p, ring r)
{
+ #ifndef X_OMALLOC
pAssumeReturn(r != NULL && r->PolyBin != NULL);
+ #endif
pAssumeReturn(p != NULL);
return p_LmCheckIsFromRing(p, r);
}
BOOLEAN p_CheckRing(ring r)
{
+ #ifndef X_OMALLOC
pAssumeReturn(r != NULL && r->PolyBin != NULL);
+ #endif
return TRUE;
}

[Nils Bruin]

Do these need the same treatment?

kernel/kutil.cc:669: omCheckBinAddrSize(T->max, (tailRing-
>PolyBin->sizeW)*SIZEOF_LONG);
kernel/pDebug.cc:83: omSizeWOfAddr(p)==r-
>PolyBin->sizeW) ||
kernel/pDebug.cc:91: pPolyAssumeReturn(omIsBinPageAddr(p) &&
omSizeWOfAddr(p)==r->PolyBin->sizeW,p,r);
kernel/pDebug.cc:214: pPolyAssumeReturnMsg(omTestBinAddrSize(p, (r-
>PolyBin->sizeW)*SIZEOF_LONG, level+1)
kernel/pDebug.cc:234: pPolyAssumeReturnMsg(omTestBinAddrSize(p, (r-
>PolyBin->sizeW)*SIZEOF_LONG, 1)
kernel/pShallowCopyDelete.cc:21: assume(d_bin == d_r->PolyBin ||
d_bin->sizeW == d_r->PolyBin->sizeW);
kernel/pInline1.h:97: pAssume1(bin != NULL && r->PolyBin->sizeW ==
bin->sizeW);
kernel/pInline1.h:180: pAssume1(bin->sizeW == r->PolyBin->sizeW);
kernel/pInline2.h:299: pAssume2(bin != NULL && r->PolyBin->sizeW ==
bin->sizeW);
kernel/pInline2.h:481: pAssume2(r->PolyBin->sizeW == bin->sizeW);

It would be nice if it were possible to extend xalloc so that PolyBin
can be dereferenced. It's usually best if debug code is as close as
possible to the original.
Would it be hard to rudimentarily support PolyBin (i.e., I guess have
it assigned a value such that r->PolyBin->sizeW == bin->sizeW in most
contexts)

I guess that omalloc with "emulate" option fails to produce a working
executable for similar reasons then? That the malloc substitutes don't
implement all the things Singular relies on?

[Simon King]

Dear Hans, dear Nils,

Zitat von Nils Bruin <bruin...@gmail.com>:

> Do these need the same treatment?

My impression is that the sizeW member needs some care. It is of
course used in omalloc/, but also in kernel, namely:

1)
./kernel/kutil.cc: omCheckBinAddrSize(T->max,
(tailRing->PolyBin->sizeW)*SIZEOF_LONG);
./kernel/pDebug.cc: pPolyAssumeReturnMsg(omTestBinAddrSize(p,
(r->PolyBin->sizeW)*SIZEOF_LONG, level+1)
./kernel/pDebug.cc: pPolyAssumeReturnMsg(omTestBinAddrSize(p,
(r->PolyBin->sizeW)*SIZEOF_LONG, 1)

=> not critical, omCheckBinAddrSize and omTestBinAddrSize should
simply confirm that there is no error.

2)
./kernel/pInline1.h: pAssume1(bin != NULL && r->PolyBin->sizeW ==
bin->sizeW);
./kernel/pInline1.h: pAssume1(bin->sizeW == r->PolyBin->sizeW);
./kernel/pShallowCopyDelete.cc: assume(d_bin == d_r->PolyBin ||

d_bin->sizeW == d_r->PolyBin->sizeW);

./kernel/pInline2.h: pAssume2(bin != NULL && r->PolyBin->sizeW ==
bin->sizeW);
./kernel/pInline2.h: pAssume2(r->PolyBin->sizeW == bin->sizeW);

=> simple comparisons - one could make them hold true by defining
sizeW constant.

3)
./kernel/pDebug.cc:
omSizeWOfAddr(p)==r->PolyBin->sizeW) ||
./kernel/pDebug.cc: pPolyAssumeReturn(omIsBinPageAddr(p) &&
omSizeWOfAddr(p)==r->PolyBin->sizeW,p,r);

=> related with 2: if one keeps sizeW constant, then omSizeWOfAddr
should return the same constant.

4)
./kernel/tgb.cc: memmove (np, p, b->sizeW * sizeof (long));

=> may seem critical. Here, a chunk of memory is moved, and thus the
size really matters. Or does it? This line occurs as follows:
#ifdef HEAD_BIN
static inline poly p_MoveHead (poly p, omBin b)
{
poly np;
omTypeAllocBin (poly, np, b);
memmove (np, p, b->sizeW * sizeof (long));
omFreeBinAddr (p);
return np;
}
#endif

But fortunately, we have
> grep "define HEAD_BIN" -R .
./kernel/tgb_internal.h://#define HEAD_BIN

In other words, the definition of HEAD_BIN is commented out!

----------------

My conclusion:
It would make sense to have omBin->sizeW available (for the reason
expressed by Nils), and I think one could make sure "->sizeW" always
is, say, 1.

Best regards,

[Simon King]

Hi Nils,

Am Mittwoch, 28. November 2012 22:12:18 UTC+1 schrieb Simon King:

My impression is that the sizeW member needs some care.

I tried to make that work. But I am afraid I failed miserably.

Then I did as suggested by Hannes. After some minor additional fixes (such as including stdio.h somewhere) it did build, and I even got a Singular executable to start. However, one immediately gets a segfault as soon as any computation is done.

Back to the drawing board :-(

Best regards,
Simon

[Simon King]

Hi Nils and Hannes,

Zitat von Simon King <simon...@uni-jena.de>:

> Then I did as suggested by Hannes. After some minor additional fixes (such
> as including stdio.h somewhere) it did build, and I even got a Singular
> executable to start. However, one immediately gets a segfault as soon as
> any computation is done.
>
> Back to the drawing board :-(

As it turns out, there are a couple of macros for deallocating omBin -
but it seems to be a bad idea to free an omBin if it is (according to
Hannes) now just a size_t.

So, after removing omBin..., I was able to do a non-trivial
computation in Sage:
sage: A.<x,y> = FreeAlgebra(QQ, 2)
sage: P.<x,y> = A.g_algebra({y*x:-x*y})
sage: x._mul_(y)
x*y

Only when exiting Sage, I got
*** glibc detected *** python: free(): invalid pointer: 0x000000000507f580 ***

And I do *not* get a crash with the Singular executable after a short
computation:
> ring r;
> x;
x
> x*y+z;
xy+z
> Auf Wiedersehen.

Hence, my suggestion to Nils is that we now return to the Sage trac
ticket - agreed?

Thank you for all the input from libsingular-devel!

[Simon King]

Dear libsingular developers,

Am Donnerstag, 29. November 2012 13:13:13 UTC+1 schrieb Simon King:

Hence, my suggestion to Nils is that we now return to the Sage trac  
ticket - agreed?

For your information: Meanwhile we have a new Singular spkg on http://trac.sagemath.org/sage_trac/ticket/13731 which backports the bug fixes from Singular trac ticket #463, and which provides the option to replace omalloc by xalloc. And the good news: The Sage test suite passes, even though I've set MALLOC_CHECK_=3 - without the backported fixes, we would see numerous crashes.

In other words, Singular is now officially bug free ;-)

Best regards,
Simon