> If this is confirmed, I don't mind using a more sane parent for the > tests. On the other hand, getting a segfault with an (admittedly ill) > piece of pure Python code is not good. Could any expert of the arcanes > of Integer comparison have a look? >
Yep, using ZZ as a parent for something which isn't of class sage.rings.integer.Integer is what was causing the segfault here. There's actually a bit more to the story -- in particular, one should wonder why it only segfaulted on OSX. I'll make some comments about what was going on below; more importantly, though, is what we should do about fixing it. In general, there are a lot of parents that assume that elements with that parent are of some fixed type; breaking this rule would be bad on two counts: (1) we'd pay the price by having to do a bunch of typechecks everywhere, which is no good, and (2) the logic that depends on this isn't clearly defined -- it's just an *implicit* assumption in lots of code all over the place. So how should we fix it? Robert Bradshaw pointed out that there should probably be a corresponding ParentWrapper, that one could use to create wrapped parents for the wrapped elements. In fact, I think we should go one step further -- I don't see why you should be able to end up with an ElementWrapper without the corresponding ParentWrapper. So passing parent=P should probably just create a wrapper out of P, if it isn't one already. In general, being able to just choose your parent out of the blue is a dangerous thing ... this might be a reasonably controlled way to do so. In the short term, someone needs to change up the docstrings in element_wrapper.py, and at the very least, put a big warning in about the dangers of getting to choose your parents. (There's surely a good joke I'm missing here.) Nicolas, it might make the most sense for you to modify the docstrings, if you have time ... Now for the interesting part: what was going on? Well, the example on the ticket creates an integer wrapper object, and then calls into the integer comparison code with it. Since the two have identical parents, the code lets it in, and passes it off to a function that implicitly assumes both inputs are of type sage.rings.integer.Integer. Once that code (_cmp_c_impl) gets its hands on them, it calls off to the gmp mpz_cmp function to do a comparison on the two underlying mpz_ts. However, the second argument was some other random Python object -- so, on OS X, it ends up taking some random chunk of the object, and dereferencing it ... boom. But why only on OSX? The sage.rings.integer.Integer object stores just a bit of information and an mpz_t; the mpz_t is the number of allocated limbs, the number of used limbs, and a pointer to the limbs. I just ended up printing out the relevant bytes on my laptop and sage.math ... on my laptop, both of the first two entries were just large numbers. However, on sage.math, it happens that in the same situation, the second entry happened to be all zeros. That means that when mpz_cmp looks at the number, it decides that it's just zero, and does the comparison without ever trying to actually access the limbs -- so it works, except that it pretends the number is 0. (Indeed, 0 == a will return True on sage.math, for a as in the description on #8177.) I just chatted with Robert Bradshaw, and at least in one example on my laptop, creating a weakref will "fix" the problem -- no more segfault. But then, you've still got a nonsense value it found elsewhere in memory. (Interestingly, on his machine, he has the opposite behavior -- a acts like 0 before the weakref, and segfaults once it's there.) -cc -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
