Bug in solve?

[Rolandb]

Hi,

 

Using 5.7 in Windows 64, I got the following message:

 

solution=solve([(a*x+b*y)*x*y/c==1,3*log(a + b + c) - log(27*a*b*x*y)],x,y,solution_dict=True)

for sol in solution: show(sol)

 

;;;
;;; Detected access to protected memory, also kwown as 'bus or
segmentation fault'.
;;; Jumping to the outermost toplevel prompt
;;;

Roland

[Jan Groenewald]

Hi

I also get this on Ubuntu 12.04.2 sage 5.7 64bit (binary).

;;;
;;; Detected access to protected memory, also kwown as 'bus or segmentation fault'.
;;; Jumping to the outermost toplevel prompt
;;;

Right after running solve, this message appears many times (several seconds long)

until

;;;
;;; Detected access to protected memory, also kwown as 'bus or segmentation fault'.
;;; Jumping to the outermost toplevel prompt
;;;

/usr/bin/sage: line 135:  6511 Segmentation fault      "$SAGE_ROOT/spkg/bin/sage" "$@"

Also note this error when running sage -gdb

0 jan@osprey:~$sage -gdb
----------------------------------------------------------------------
| Sage Version 5.7, Release Date: 2013-02-19                         |
| Type "notebook()" for the browser-based notebook interface.        |
| Type "help()" for help.                                            |
----------------------------------------------------------------------
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /usr/lib/sagemath/local/bin/python...(no debugging symbols found)...done.
/tmp/tmpThUpcH:4: Error in sourced command file:
/home/buildbot/build/sage/snapperkob/snapperkob_binary/build/sage-5.7/local/bin/python: No such file or directory.
/usr/lib/sagemath/local/bin/sage-gdb-commands:1: Error in sourced command file:
No executable file specified.
Use the "file" or "exec-file" command.
(gdb)

This is from the PPA repackage of the binary built on buildbot, the buildbot's hostname is snapperkob.

I will test it on a from-source compile once it has compiled.

Regards,
Jan

--
You received this message because you are subscribed to the Google Groups "sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-support...@googlegroups.com.
To post to this group, send email to sage-s...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
  .~.
  /V\     Jan Groenewald
 /( )\    www.aims.ac.za
 ^^-^^

[Jan Groenewald]

Hi

The error persists on a ubuntu 12.04.2 from-source install:

;;;
;;; Detected access to protected memory, also kwown as 'bus or segmentation fault'.
;;; Jumping to the outermost toplevel prompt
;;;

./sage: line 135:  5791 Segmentation fault      "$SAGE_ROOT/spkg/bin/sage" "$@"

Now I can sage -gdb the from-source install:

sage: solve([(a*x+b*y)*x*y/c==1,3*log(a + b + c) - log(27*a*b*x*y)],x,y,solution_dict=True)

Program received signal SIGSEGV, Segmentation fault.
ecl_bds_unwind (env=0x7ffff7fed000, new_bds_top_index=<optimised out>)
    at /srv/local/Disk_Space/jan/sage-5.7/spkg/build/ecl-12.12.1.p1/src/src/c/stacks.d:173
173     /srv/local/Disk_Space/jan/sage-5.7/spkg/build/ecl-12.12.1.p1/src/src/c/stacks.d: No such file or directory.
(gdb)

The build directory is empty.

Some references from a quick google search of ecl + access to protected memory:
http://www.mail-archive.com/ecls...@lists.sourceforge.net/msg02367.html
http://trac.sagemath.org/sage_trac/ticket/13364

Regards,

Jan

[Jean]

Hello there,

I have the same behavior on Fedora 18 x86_64

;;;

;;; Detected access to protected memory, also kwown as 'bus or segmentation fault'.

;;; Jumping to the outermost toplevel prompt

;;;

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

TypeError                                 Traceback (most recent call last)

<ipython-input-7-524b3559a41c> in <module>()

----> 1 solution=solve([(a*x+b*y)*x*y/c==Integer(1),Integer(3)*log(a + b + c) - log(Integer(27)*a*b*x*y)],x,y,solution_dict=True)

/usr/lib64/python2.7/site-packages/sage/symbolic/relation.pyc in solve(f, *args, **kwds)

    751             s = []

    752 

--> 753     sol_list = string_to_list_of_solutions(repr(s))

    754 

    755     # Relaxed form suggested by Mike Hansen (#8553):

/usr/lib64/python2.7/site-packages/sage/symbolic/relation.pyc in string_to_list_of_solutions(s)

    456     from sage.calculus.calculus import symbolic_expression_from_maxima_string

    457     v = symbolic_expression_from_maxima_string(s, equals_sub=True)

--> 458     return Sequence(v, universe=Objects(), cr_str=True)

    459 

    460 ###########

/usr/lib64/python2.7/site-packages/sage/structure/sequence.pyc in Sequence(x, universe, check, immutable, cr, cr_str, use_sage_types)

    298             return Sequence_generic(x, universe, check, immutable, cr, cr_str, use_sage_types)

    299     else:

--> 300         return Sequence_generic(x, universe, check, immutable, cr, cr_str, use_sage_types)

    301 

    302 class Sequence_generic(sage.structure.sage_object.SageObject, list):

/usr/lib64/python2.7/site-packages/sage/structure/sequence.pyc in __init__(self, x, universe, check, immutable, cr, cr_str, use_sage_types)

    502         self.__universe = universe

    503         if check:

--> 504             x = [universe(t) for t in x]

    505         list.__init__(self, x)

    506         self._is_immutable = immutable

TypeError: 'sage.symbolic.expression.Expression' object is not iterable

[Robert Dodier]

That looks like an error message from ECL. I'm guessing Sage has
translated 'solve' here to Maxima's 'to_poly_solve'. I get this with ECL
12.2.1 + current (post-5.29) Maxima source on Linux.

(%i1) load (to_poly_solve);

Loading maxima-grobner $Revision: 1.6 $ $Date: 2009-06-02 07:49:49 $
(%o1)
/home/robert/maxima/maxima-git/maxima-code/share/to_poly_solve/to_poly_s\
olve.mac
(%i2) to_poly_solve ([(a*x+b*y)*x*y/c=1,3*log(a + b + c) -
log(27*a*b*x*y)],[x,y]);

Maxima encountered a Lisp error:

BINDING-STACK overflow at size 8448. Stack can probably be resized.

Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
Maxima encountered a Lisp error:

Detected access to an invalid or protected memory address.

Automatically continuing.


Looks like a stack overflow in to_poly_solve -- I didn't go farther. Can
someone please submit a bug report. http://sourceforge.net/p/maxima/bugs

best

Robert Dodier

[Jan Groenewald]

Hi

On 25 February 2013 01:06, Robert Dodier <robert...@gmail.com> wrote:

Looks like a stack overflow in to_poly_solve -- I didn't go farther. Can
someone please submit a bug report. http://sourceforge.net/p/maxima/bugs

 https://sourceforge.net/p/maxima/bugs/2553/

Regards,
Jan

[Emmanuel Charpentier]

This seems ECL-specific. A GCL-based Maxima installation does not encounter this (and does not solve the problem either) :

Maxima 5.29.1 http://maxima.sourceforge.net

using Lisp GNU Common Lisp (GCL) GCL 2.6.7 (a.k.a. GCL)

Distributed under the GNU Public License. See the file COPYING.

Dedicated to the memory of William Schelter.

The function bug_report() provides bug reporting information.

[ ... ]

(%i5) to_poly_solve ([(a*x+b*y)*x*y/c=1,3*log(a + b + c) - 

log(27*a*b*x*y)],[x,y]);

(%o5) %solve([3*log(c+b+a)-log(27*a*b*x*y),x*y*(b*y+a*x)/c = 1],[x,y])

HTH,

                                                                           Emmauel Charpentier

[Stan Schymanski]

Using 5.8 in Ubuntu 12.10, I get the same segmentation fault message in a looping code without involving any solve() command. I am just using a series of equations to calculate different values of variables saved in a dictionary ("vdict") and substitute those in the next equations, e.g.: vdict[var1] = eq_var1.rhs().subs(vdict).
If I run the code for a long series of loops, eventually I get:

;;;
;;; Detected access to protected memory, also kwown as 'bus or
segmentation fault'.
;;; Jumping to the outermost toplevel prompt
;;;

Does the .subs(vdict) command use maxima? How can I help debugging this?

Cheers,
Stan

[Jan Groenewald]

Hi Stan,

Did you download sage-5.8-linux-64bit-ubuntu_12.04.2_lts-x86_64-Linux.tar.lzma

and untar that?  That is not a from-source compile.

You can run sage -gdb instead of sage only if you compiled from source, and see what the output is when you run your code via that.

Regards,
Jan

--

You received this message because you are subscribed to the Google Groups "sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sage-support...@googlegroups.com.
To post to this group, send email to sage-s...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-support?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[kcrisman]

On Friday, March 29, 2013 6:14:21 AM UTC-4, Stan Schymanski wrote:

Using 5.8 in Ubuntu 12.10, I get the same segmentation fault message in a looping code without involving any solve() command. I am just using a series of equations to calculate different values of variables saved in a dictionary ("vdict") and substitute those in the next equations, e.g.: vdict[var1] = eq_var1.rhs().subs(vdict).
If I run the code for a long series of loops, eventually I get:

;;;
;;; Detected access to protected memory, also kwown as 'bus or
segmentation fault'.
;;; Jumping to the outermost toplevel prompt
;;;

Does the .subs(vdict) command use maxima? How can I help debugging this?

This should only use Ginac/Pynac.  If you can post the code you are using somewhere like pastebin, maybe one could look to see if Maxima is implicitly used somewhere.  Do you ever use one of the simplification commands? 

[Stan Schymanski]

Hi Jan,

I did compile from source on my local laptop. Here is what I got when trying sage -gdb:

 sage -gdb
----------------------------------------------------------------------
| Sage Version 5.8, Release Date: 2013-03-15                         |

| Type "notebook()" for the browser-based notebook interface.        |
| Type "help()" for help.                                            |
----------------------------------------------------------------------

The Sage installation tree has moved
from /home/sschyman/Programs/sage-5.8
  to /home/sschyman/Programs/sage
Updating various hardcoded paths...
(Please wait at most a few minutes.)
DO NOT INTERRUPT THIS.
Done updating paths.
GNU gdb (GDB) 7.5-ubuntu

Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/sschyman/Programs/sage/local/bin/python...done.
Python was not compiled with debug symbols (or it was stripped). Some functionality may not work (properly).
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
warning: File "/home/sschyman/Programs/sage/local/lib64/libstdc++.so.6.0.16-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".

[Stan Schymanski]

Thanks for offering to look into it, kcrisman.
I wasn't able to isolate the error yet, but I uploaded a slightly trimmed worksheet here:
https://sagenb.kaist.ac.kr:8066/home/pub/59
Contrary to my previous impression, this error is now reproducible, as in it happens at the same point every time now. Maybe it is an error in my code after all...

Cheers
Stan

[kcrisman]

On Friday, March 29, 2013 12:39:48 PM UTC-4, Stan Schymanski wrote:

Thanks for offering to look into it, kcrisman.
I wasn't able to isolate the error yet, but I uploaded a slightly trimmed worksheet here:
https://sagenb.kaist.ac.kr:8066/home/pub/59
Contrary to my previous impression, this error is now reproducible, as in it happens at the same point every time now. Maybe it is an error in my code after all...

You definitely use Maxima simplification a few times, but it doesn't appear to intersect with the code that is repeated so often (fun_dynamics etc.).  Hmm.  If you could try to remove a lot of that stuff it would be really helpful; that is a very impressively long worksheet! 

[Stan Schymanski]

I just found out that adding an additional print command in fun_dynamics makes the crash move to a different position. The last number printed was 354 before, now it is 88 a lot further down the track. So it seems indeed to be a matter of filling up memory, and not a particular combination of numbers or a call of a particular function. This will make it very difficult to troubleshoot, as simplifying the worksheet might make the error go away.
I republished the slightly modified worksheet here, FYI:
https://sagenb.kaist.ac.kr:8066/home/pub/60
Any idea how to shed more light into this?

Cheers
Stan

[Stan Schymanski]

Only 2 years later, and I found a way around segmentation faults due to memory problems. It seems that my looping functions fill up memory over time and lead to segmentation faults at random stages. I now define such functions using the @fork decorator and then they don't seem to cause crashes any more (memory gets freed after each run). Just in case someone with a similar problem stumbles over this.

[kcrisman]

Only 2 years later, and I found a way around segmentation faults due to memory problems. It seems that my looping functions fill up memory over time and lead to segmentation faults at random stages. I now define such functions using the @fork decorator and then they don't seem to cause crashes any more (memory gets freed after each run). Just in case someone with a similar problem stumbles over this.

Huh.  Maybe this would be worth adding to the documentation... somewhere, I have no idea where. 

[William Stein]

This would go well in the FAQ.

http://sagemath.org/doc/faq/

Will


--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[kcrisman]

>> Only 2 years later, and I found a way around segmentation faults due to
>> memory problems. It seems that my looping functions fill up memory over time
>> and lead to segmentation faults at random stages. I now define such
>> functions using the @fork decorator and then they don't seem to cause
>> crashes any more (memory gets freed after each run). Just in case someone
>> with a similar problem stumbles over this.
>
>

Stan, do you have a fairly small (in terms of code length, I mean, not timing or anything) example that could be used to demonstrate how @fork avoids this problem?

 

> Huh.  Maybe this would be worth adding to the documentation... somewhere, I
> have no idea where.

This would go well in the FAQ.

Yeah, I guess.  See http://trac.sagemath.org/ticket/17604 and hopefully we can put a good example there.