# GeoGebra crashes when dragging the parameter to a definite integral

SeL shared this problem 6 years ago
Not a Problem

Hi, this applies to GeoGebra on an up-to-date Arch Linux, that is GeoGebra 5.0.290.0-3D (11 November 2016) under Java 1.8.0_121, on a fairly old HP notebook with 4 GB.

I wanted to put the calculation of the circumference of a circle in L(p) space, i.e. measured using the p-norm into GeoGebra. You have probably seen this: dividing this circumference by the diameter yields a “variable value for π”, π(p). For p=2, the norm is the Euclidian norm and takes π(p) to the standard value which is also a global minimum for the function p→π(p).

Being lazy, I used the integral formula for π(p) found at http://math.stackexchange.c... – I constructed the “p-circle” (requiring 4 loci as each locus would end considerably before its endpoint for higher values of p). Also, but not relevant to the crash, I transformed p using the function p→p/(1-p) as this way I could use [0, 1] as the input range and obtain the desired [1, ∞] interval for p with the interesting value 2 in the middle (as 0.5 maps to 2 with this transformation).

Obviously I have a slider for p that I want to drag to see how the shape of the p-circle changes. That same slider also provides the parameter for the calculation for π(p) via the definitive integral formula found on Mathematics Stack Exchange. When I drag p, GeoGebra crashes. Also, if I try to construct a Locus to draw the graph for p→π(p) GeoGebra crashes almost instantly. Actually I was able to construct the Locus and immediately save and close the file, in which case GeoGebra would crash as soon it tries to reopen the file. Luckily I know how to edit the XML definition of the construction so I could bring those files back to a usable state.

The attached file “p-circle.ggb” does open but crashes when I drag p. Some careful dragging across small values or double-clicking and entering values for p is possible. The second file “p-circle-reduced.ggb” does not crash, the difference being that it does not try to calculate or graph π(p), only show the p-circle.

1

Erratum: my transformation p→p/(1-p) maps [0, 1] to [0, ∞] of course with the middle value ½ mapping to 1, not 2. I need the source value ⅔ to get p=2.

Problems mostly occur once I pass ⅔ (corresponding to p=2) on the slider, and as p exceeds 5 my formula won’t calculate at all in GeoGebra – the output says “π(p)=?” although the integral can be computed (e.g. π(6)≈3.57).

1

1

Arch Linux doesn’t provide a newer version yet so I tried the portable package from the download page. That is version 5.0.328.0 so slightly older than you asked. I still got a crash and the following output on the terminal from where I had started it:

1. GeoGebra 5.0.328.0 12 February 2017 Java 1.7.0_45-64bit21:58:03.932 DEBUG: org.geogebra.desktop.i.a.<init>[-1]: isApplet=false runningFromJar=true appletImpl=null

21:58:03.933 DEBUG: org.geogebra.desktop.i.a.aC[-1]: Setting up logging

21:58:03.957 DEBUG: org.geogebra.desktop.i.a.aC[-1]: Logging is redirected to /tmp/GeoGebraLog_jorwhjqwob.txt

Temporary replacing surd/NTHROOT by fractional powers

Simplification assuming ggbtmpvarpunicode39u near 0

Simplification assuming ggbtmpvarpunicode39u near 0

Undef/Unsigned Inf encountered in limit

Undef/Unsigned Inf encountered in limit

Undef/Unsigned Inf encountered in limit

Undef/Unsigned Inf encountered in limit

Undef/Unsigned Inf encountered in limit

Undef/Unsigned Inf encountered in limit

Simplification assuming ggbtmpvarpunicode39u near 0

Simplification assuming ggbtmpvarpunicode39u near 0

Undef/Unsigned Inf encountered in limit

Undef/Unsigned Inf encountered in limit

Undef/Unsigned Inf encountered in limit

Undef/Unsigned Inf encountered in limit

Undef/Unsigned Inf encountered in limit

Undef/Unsigned Inf encountered in limit

Low accuracy, error estimate 6.554850513688E-10

Error might be underestimated if initial boundary was +/-infinity

Low accuracy, error estimate 5.85430063334E-11

Error might be underestimated if initial boundary was +/-infinity

Adaptive method failure, will try with Romberg, last approximation was ?

#

# A fatal error has been detected by the Java Runtime Environment:

#

# SIGILL (0x4) at pc=0x00007f9f805b785b, pid=4700, tid=140324801726208

#

# JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build 1.7.0_45-b18)

# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode linux-amd64 compressed oops)

# Problematic frame:

# C [libjavagiac640.1258809581480408.so+0xbee85b] __gmpn_popcount+0x5b

#

# Core dump written. Default location: [redacted]

#

# [redacted]

#

# If you would like to submit a bug report, please visit:

# The crash happened outside the Java Virtual Machine in native code.

# See problematic frame for where to report the bug.

#

Aborted (core dumped)

The core file that is mentioned in the output is not there but the log file is. I’ve attached it (username and paths redacted).

1

Please post the contents of this file:

1. /tmp/GeoGebraLog_jorwhjqwob.txt

1

Here it is. Thanks for going to the trouble by the way :‑)

1

Can't see anything wrong there sadly...

What value of p kills it? (you can confirm by typing eg p=1.2345 in the Input Bar)

Does it help if you change the slider's increment to 0.01? (then the values of p will be "nicer")

1

No single value kills it, I can enter any value for p (both for the original and transformed p). When I wrote above that “double-clicking and entering values for p is possible” I meant exactly what you suggested here, manually entering a value or changing the slider value by carefully spaced, single mouse clicks on the slider. p=2 (or ⅔ on my slider) does seem to be of critical importance. Crashes almost only occur, it seems, when I pass p=2 and possibly p=5 while dragging. I had set the increment to 0.033… (ending with a 3 or 4 as a rounding experiment) so that the slider would stop at ⅔ as closely as possible. Setting the increment to 0.01 does indeed avoid the problem, I can then drag as freely and wildly as I want in both versions without getting a crash.

One problem that persists is that “π(p)=?” is shown for p≥5.

Thanks again. GeoGebra is a great programme regardless how far we can get with this :‑)

1

Trying to search for the exact value for p at which π(p) switches to “?”, I am now able to kill my older GeoGebra (I deleted the newer portable version as it doesn’t seem to make a difference for me) by entering a single value for p. Well p' to be precise, I didn’t use the transformation p→p/(1−p) for this investigation. I removed the slider for p and included one for p' (and changed the Rounding option to 15 digits), but I’m not dragging the slider. Instead I open the properties for p' and enter values manually. The attached file “p-circle-maxp.gbb” shows the state just before the refinement that kills it. The value for p' in the file is 4.7422821357746. Adding a 5 as a new last digit kills the process immediately. I’ve also attached the two files that log this crash. The terminal output says (reduced):

1. Low accuracy, error estimate 9.999999250487E-05

Error might be underestimated if initial boundary was +/-infinity

Low accuracy, error estimate 9.987226920615E-05

Error might be underestimated if initial boundary was +/-infinity

#

# A fatal error has been detected by the Java Runtime Environment:

#

# SIGILL (0x4) at pc=0x00007f67fe0741db, pid=10300, tid=0x00007f6810365700

#

# JRE version: OpenJDK Runtime Environment (8.0_121-b13) (build 1.8.0_121-b13)

# Java VM: OpenJDK 64-Bit Server VM (25.121-b13 mixed mode linux-amd64 compressed oops)

# Problematic frame:

# C [libjavagiac640.8597284700441075.so+0xc401db] __gmpn_popcount+0x5b

1

I have now tried this on an even older machine with Windows XP (don’t ask …), using the portable version for Windows which is version 5.0.331.0-3D. I was not able to produce a crash there. The “π(p)=?” phenomenon continued to exist and I was able to narrow down the threshold value until I lost interest at [4.742282135774643858638910387526266276836395…4.742282135774643858638910387526266276836396]. In my original file I was able to drag p freely and also construct the graph p→π(p) as Locus(A, p). Not surprisingly, GeoGebra became extremely slow at that point, taking tens of seconds to respond to any action – this even persisted after I closed the file and tried to construct a line in a new construction.

1

The portable version for Linux is now up to 5.0.331.0-3D as well so out of curiousity I tried it – still crashing e.g. when I set p (or rather p') to 4.7422821357746 and append the digit 5. The stacktrace in the logfile looks much the same:

1. Stack: [0x00007fddae9e6000,0x00007fddaeae7000], sp=0x00007fddaead4548, free space=953k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)

C [libjavagiac640.7953683211087424.so+0xbeed1b] __gmpn_popcount+0x5b

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)

j javagiac.giacJNI.new_gen__SWIG_25(Ljava/lang/String;JLjavagiac/a;)J+0

j javagiac.b.<init>(Ljava/lang/String;Ljavagiac/a;)V+7

j org.geogebra.common.l.a.a.a.b(Ljava/lang/String;J)Ljava/lang/String;+46

j org.geogebra.common.l.a.a.a.a(Ljava/lang/String;J)Ljava/lang/String;+71

j org.geogebra.common.b.b.a.b(Ljava/lang/String;)Ljava/lang/String;+8

j org.geogebra.common.b.d.a(Ljava/lang/String;)Ljava/lang/String;+21

j org.geogebra.common.m.w.b(Ljava/lang/String;)Ljava/lang/String;+32

j org.geogebra.common.m.g.j.g()V+117

j org.geogebra.common.m.g.j.b()V+157

j org.geogebra.common.m.c.aH.w_()V+14

j org.geogebra.common.m.c.fj.a()V+13

j org.geogebra.common.m.j.B.M()V+47

j org.geogebra.common.m.j.B.y(Z)V+17

j org.geogebra.common.m.j.B.z(Z)V+2

j org.geogebra.common.m.j.B.e_()V+2

j org.geogebra.common.m.h.a.a(Lorg/geogebra/common/m/j/B;[Lorg/geogebra/common/m/j/B;Lorg/geogebra/common/m/d/ab;Lorg/geogebra/common/m/h/bG;)V+207

j org.geogebra.common.m.h.a.a(Lorg/geogebra/common/m/d/ab;Lorg/geogebra/common/m/h/bG;)[Lorg/geogebra/common/m/j/B;+145

j org.geogebra.common.m.h.a.a(ZLorg/geogebra/common/n/a/a;Lorg/geogebra/common/m/d/ab;Lorg/geogebra/common/m/h/bG;)[Lorg/geogebra/common/m/j/B;+7

1

I tried to reproduce the crash under Ubuntu Linux 14.04.5 and 16.04.2 with the file p-circle-maxp.ggb, but without success. (I experienced no crash when appending the digit 5, and also everything worked smoothly when dragging the slider for several seconds.)

Is it possible for you to try a different Linux version as well? The underlying computer algebra system does not rely on any specific libraries. The crash report

C [libjavagiac640.8597284700441075.so+0xc401db] __gmpn_popcount+0x5b

C [libjavagiac640.8597284700441075.so+0xc223cb] mpfr_strtofr+0x75b

means that the crash occured in GMP/MPFR which are embedded libraries of our embedded computer algebra system Giac. Since they use only libc calls, the only difference I can imagine is that your Arch Linux uses a different version of libc. (Ubuntu uses 2.19-0ubuntu6.9 and 2.23-0ubuntu5, respectively.) According to https://www.archlinux.org/p..., Arch Linux's libc version is 2.24-2. I guess "pacman -Qe | grep libc" will give you the version number (I am not familiar with Arch Linux, unfortunately).

1

On my system the package is also called glibc with version 2.24-2.

1

I have now tried another Linux, by downloading the latest Linux Mint release (the Ubuntu-based version), writing it to a USB stick and booting from it. I then installed the latest GeoGebra version from the website (now 5.0.331.0 as you will know – Mint currently has version 4.2.60.0-30762 in its repositories). The libc packages (libc-bin, libc6) have version 2.23-0ubuntu5. On my personal laptop, where I first saw this error, nothing had changed. GeoGebra crashes as before (similar stack information, I have attached files for two crashes but they probably don’t contain anything interesting). I then booted the same linux on a more modern laptop (a Dell from 2011, 8 GB RAM) and could not produce a crash. Now wondering whether I’ll need to get details on CPU models :‑)

Deviating slightly from the original problem, constructing Locus(A, p) in “p-circle.ggb” would of course crash on the older HP but on the Dell, surprisingly, the experience was worse than on that much older Windows XP desktop. One of the four CPUs went to 100 % for minutes and the window did not respond at all, I ended up killing the process.

1

I think this may be rather a memory problem and not related to libc. GeoGebra may run out of memory on 4 GB RAM (but on my machine I don't experience any extensive memory usage for your example). Another problem can be that you have corrupted memory because of hardware failure.

Maybe it would be useful to see /var/log/syslog as well.

1

Did you use 64 bit system during all tests? As far as I can remember, Giac may fail on a 32 bit system in some cases.

1

But doesn’t the fact that appending that single digit to a certain value of p' reliably crashes GeoGebra somewhat disprove the corrupted memory hypothesis? I would expect the effect to be much more random.

Nothing new in the syslog by the way, instead of this somewhat more detailed final stack trace which I don’t expect to be of value:

1. Feb 19 14:19:47 Io systemd-coredump[18547]: Process 18437 (java) of user 1000 dumped core.

#0 0x00007f655964204f raise (libc.so.6)

#1 0x00007f655964347a abort (libc.so.6)

#2 0x00007f6558f7c719 n/a (libjvm.so)

#3 0x00007f65591252ef n/a (libjvm.so)

#4 0x00007f6558f85475 JVM_handle_linux_signal (libjvm.so)

#5 0x00007f6558f79d78 n/a (libjvm.so)

#7 0x00007f650cf491db n/a (/tmp/libjavagiac640.07388511161948219.so (deleted))

1

All tests were on 64-bit systems with 64-bit software, yes. (Except the one on Windows XP I guess)

1

Please could you try the following?

1. Start GeoGebra.
2. Open View > CAS.
3. Copy-paste this in the CAS View: @evalf(integrate(surd(((x)^((1)-(exact(4.74128213577465))))+(((1)-(x))^((1)-(exact(4.74128213577465)))),exact(4.74128213577465))^(1),x,0.000000000000,1.000000000000))
4. Press ENTER.

Does GeoGebra immediately crash?

1

Yes, it does. Logfile attached.

1

It's a strange problem. You may want to play a bit more by installing Giac (see http://www-fourier.ujf-gren...) and enter the above CAS command without the leading @. You should get something like

\$ giac

// Using locale /usr/share/locale/

...

Press CTRL and D simultaneously to finish session

Type ?commandname for help

0>> evalf(integrate(surd(((x)^((1)-(exact(4.74128213577465))))+(((1)-(x))^((1)-(exact(4.74128213577465)))),exact(4.74128213577465))^(1),x,0.000000000000,1.000000000000))

Low accuracy, error estimate 9.98722692061e-05

Error might be underestimated if initial boundary was +/-infinity

8.23168755766

// Time 0.03

If this crashes also, we can go on by debugging Giac natively.

1

Unfortunately I would have to compile and install Giac by hand, it seems that an older package definiton for Arch existed but has been withdrawn. (All I can find searching for Arch packages named xcas or giac is a package for a depedency, fltk-xcas. According to the compilation instructions this is a patch to a library called fltk, but the patch is no longer required as newer versions of fltk are now available.)

The instructions for manual compilation are at http://www-fourier.ujf-gren.... In the absence of a package definition for the Arch User Repository, I would either have to create one myself (preferred option as this would also take care of dependencies but this would be my first time) or compile as a user and run giac locally without executing “make install” (possible). This is not something I can do on the side, so interesting as this is, this will have to wait for a while.