Poly/ML

polyml@lists.polyml.org

2 participants
711 discussions

segmentation fault with polyml 4.2.0 on startup
by walch.martin＠web.de 23 Aug '07

23 Aug '07

Hi, when trying to run polyml 4.2.0 on Linux, I get a segmentation fault. I am trying to run this old version, because I want to use Isabelle (http://isabelle.in.tum.de/ seems to be down currently). On that website, a precompiled binary is available. However, it's crashing on startup with a SIGSEGV. So I downloaded the source code of polyml 4.2.0, extracted driver.420.tar.gz, ran configure and make and tried to run poly. But also in this version I get a segmentation fault. my kernel: uname -rm 2.6.22-gentoo-r2 i686 gdb shows this backtrace: #0 0xa7f21410 in __kernel_vsyscall () #1 0x410d4038 in mmap () from /lib/libc.so.6 #2 0x08059b34 in ReserveAddressSpace (addr=0x98000000 "", len=268435456) at mmap.c:363 #3 0x08059a41 in ReserveMLSpace (bottom=0x98000000 "", top=0xa8000000 <Address 0xa8000000 out of bounds>) at mmap.c:376 #4 0x08059b82 in ReserveMLSpaces () at mmap.c:403 #5 0x08052741 in main (argc=1, argv=0xafc18304) at mpoly.c:726 The mmap call in line 362/363 is caddr_t pa = mmap((caddr_t)addr, len, PROT_NONE, MAP_PRIVATE | MAP_FIXED | MAP_NORESERVE | MAP_ANONYMOUS, -1, 0L); when removing MAP_PRIVATE from the flags, it seems to work. I am not really in the code. Maybe you can tell me: will I run into trouble, when using this as a fix? Has anybody an idea why this call to mmap results in a segmentation fault and how to fix this properly? I played a bit with the len argument. When setting it to 267500000, sometimes it's crashing and sometimes not. len=260000000 seems to be stable. Thank you in advance Martin Walch

2 1

PolyML.cd
by itz＠madbat.mine.nu 13 Jun '07

13 Jun '07

Hi, it seems this function has suffered extinction in 5.0 - even before the onslaught of massive global warming? This would seem to quite significantly limit the flexibility of the make system, as now a multi-directory source has to strictly mirror the module and functor application structure. Worse, it makes it very hard if not impossible to use external (non-basis) sources without physically copying them to my source tree. Well, I guess there is still a way, first run make in the remote directory, dump an image, then re-run in my own directory loading that image - but it is laborious. Is there a reason why it had to go? -- This line is completely ham.

3 3

Problems compiling polyml 5 on sparc/solaris
by peter.lammich＠uni-muenster.de 05 Apr '07

05 Apr '07

with gcc 4.0.2, I get the same segfault as already reported on this list. When using gcc 3.4.3, I get the following error: ... g++ -shared -nostdlib /usr/o0/gcc-3.4.3/sparc-sun-solaris2/usr/sfw/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.3/crti.o /usr/ccs/lib/values-Xa.o /usr/o0/gcc-3.4.3/sparc-sun-solaris2/usr/sfw/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.3/crtbegin.o .libs/mpoly.o .libs/gc.o .libs/diagnostics.o .libs/arb.o .libs/reals.o .libs/timing.o .libs/processes.o .libs/profiling.o .libs/realconv.o .libs/objsize.o .libs/proper_io.o .libs/foreign.o .libs/process_env.o .libs/basicio.o .libs/network.o .libs/unix_specific.o .libs/sighandler.o .libs/xwindows.o .libs/check_objects.o .libs/scanaddrs.o .libs/polystring.o .libs/run_time.o .libs/osmem.o .libs/save_vec.o .libs/rts_module.o .libs/bitmap.o .libs/poly_specific.o .libs/exporter.o .libs/sharedata.o .libs/memmgr.o .libs/pexport.o .libs/sparc_dep.o .libs/sparc_assembly.o .libs/elfexport.o -Wl,-R -Wl,/usr/sfw/lib -Wl,-R -Wl,/usr/sfw/lib -lsocket -lnsl -ldl -lgcc -L/usr/o0/gcc-3.4.3/sparc-sun-solaris2/usr/sfw/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.3 -L/usr/o0/gcc-3.4.3/sparc-sun-solaris2/usr/sfw/bin/../lib/gcc -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3 -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../sparc-sun-solaris2.10/lib -L/usr/ccs/lib -L/usr/o0/gcc-3.4.3/sparc-sun-solaris2/usr/sfw/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.3/../../.. -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../.. /usr/sfw/lib/libstdc++.so -L/usr/sfw/lib -lm -lgcc_s /usr/o0/gcc-3.4.3/sparc-sun-solaris2/usr/sfw/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.3/crtend.o /usr/o0/gcc-3.4.3/sparc-sun-solaris2/usr/sfw/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.3/crtn.o -Wl,-h -Wl,libpolyml.so.0 -o .libs/libpolyml.so.0.0.0 ld: fatal: relocation error: R_SPARC_32: file .libs/sparc_assembly.o: symbol <unknown>: offset 0xfe34b57b is non-aligned ld: fatal: relocation error: R_SPARC_32: file .libs/sparc_assembly.o: symbol <unknown>: offset 0xfe34b581 is non-aligned ld: fatal: relocation error: R_SPARC_32: file .libs/sparc_assembly.o: symbol <unknown>: offset 0xfe34b585 is non-aligned ld: fatal: relocation error: R_SPARC_32: file .libs/sparc_assembly.o: symbol <unknown>: offset 0xfe34b589 is non-aligned ld: fatal: relocation error: R_SPARC_32: file .libs/sparc_assembly.o: symbol <unknown>: offset 0xfe3886f6 is non-aligned collect2: ld returned 1 exit status *** Error code 1 My system is [pergolesi] ~/opt/src/polyml.5.0 $ uname -a SunOS pergolesi 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Fire-V240 [pergolesi] ~/opt/src/polyml.5.0 $ gcc --version gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) Thanks in advance for any hints/help and greetings Peter Lammich

4 8

Error building Poly/ML 5
by preen＠informatik.uni-freiburg.de 26 Jan '07

26 Jan '07

Hi, I have problems building Poly/ML 5 on Solaris 10. It works fine on Linux 2.6.15. In both cases I use gcc 4.1.1. ... creating polyimport ./polyimport -H 10 imports/polymlsparc.txt < exportPoly.sml > /dev/null /bin/bash: line 1: 13236 Segmentation Fault (core dumped) ./polyimport -H 10 imports/polymlsparc.txt <exportPoly.sml >/dev/null make[2]: *** [polyexport.o] Error 139 make[2]: Leaving directory `/scratch/polyml.5.0' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/scratch/polyml.5.0' make: *** [all] Error 2 Any ideas ? Regards, Martin --------------------------------------------------------------- Martin Preen, Universit?t Freiburg, Institut f?r Informatik Georges-Koehler-Allee 52, Raum 00-006, 79110 Freiburg, Germany phone: ++49 761 203-8250 preen(a)informatik.uni-freiburg.de fax: ++49 761 203-8242 www.informatik.uni-freiburg.de

2 2

Poly/ML version 5
by David.Matthews＠prolingua.co.uk 09 Jan '07

09 Jan '07

I have updated the web site to release version 5 officially. There is a source package available at http://sourceforge.net/project/showfiles.php?group_id=148318 . Thank you everyone who provided feedback during the beta test phase. If anyone wants to make binary distributions that would be very welcome. I am hoping that will be easier now that it uses autoconf, and of course now it is licensed under LGPL. Please post a message to this list if you make a distribution so that I and other people know about it. I'm hoping to produce a Windows binary shortly. Bug fixes and other updates will continue to be made to the CVS version and will be incorporated into the next release when it happens. David.

1 0

polyml 5 heap option
by obua＠in.tum.de 14 Dec '06

14 Dec '06

Hi, I am using poly ml 5 together with Isabelle. When I start poly with the "-H 500" option, my process will terminate with a "run out of store" message after these 500MB have been used up (I used "top" to monitor the heap usage). If I give "-H 8000", it will succeed. Is this behaviour to be expected? Best, Steven -- Steven Obua Technische Universit?t M?nchen Institut f?r Informatik Boltzmannstr. 3 D-85748 Garching Tel: ++49 (0)89 / 289-17328 EMail: obua(a)in.tum.de Raum: 01.11.059

2 1

libtool -release option
by David.Matthews＠prolingua.co.uk 11 Dec '06

11 Dec '06

Ian Zimmerman wrote: > David> Ian, Since this is the first release of Poly/ML to use shared > David> libraries I would prefer to give this some thought now and then > David> adopt a scheme that can be used for future releases rather than > David> try and change it in the future. I don't have any strong > David> feelings either way and you obviously have some experience. > David> Would it be best to use -version-info 0:0:0 for this release? > > David> Because of the way the interface between compiled ML code and the > David> Poly/ML run-time library works I'll have to think about how > David> future releases should increment the version-info. > > The question is if it makes sense to upgrade the runtime and standalone > executables produced by linking with it independently. Not only for > end users, but also for distributions. > > If it does (and I think it does), then -version-info > will allow that and is preferable. The rules for incrementing the numbers > are spelled out in > > http://www.gnu.org/software/libtool/manual.html#Updating-version-info I thought about this and I've now made this change and updated CVS. The initial version is now 0:0 which is what the libtool manual suggests as the starting value. I hope that makes things simpler for Debian. David.

1 0

libtool -release option
by itz＠madbat.mine.nu 11 Dec '06

11 Dec '06

Is there a reason why this is used for libpolyml in the beta sources, instead of the -version-info or -version-number options as recommended by libtool manual? I am debianizing and lintian objects hard. -- Experience with Asset Control an asset.

2 3

Error while building PolyML 5.0 on Cygwin
by MichaelNedzelsky＠yandex.ru 10 Dec '06

10 Dec '06

After ./configure I tried to invoke make and get the following: --------------------------------------------------------------------------- $ make make all-recursive make[1]: Entering directory `/cygdrive/c/user/michael/polyml' Making all in libpolyml make[2]: Entering directory `/cygdrive/c/user/michael/polyml/libpolyml' if /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -Di386 -DLINUX -Wall -g -O3 -MT mpoly.lo -MD -MP -MF ".de ps/mpoly.Tpo" -c -o mpoly.lo mpoly.cpp; \ then mv -f ".deps/mpoly.Tpo" ".deps/mpoly.Plo"; else rm -f ".deps/mpoly.Tpo"; exit 1; fi mkdir .libs g++ -DHAVE_CONFIG_H -I. -I. -I.. -Di386 -DLINUX -Wall -g -O3 -MT mpoly.lo -MD -MP -MF .deps/mpoly.Tpo -c mpoly.cpp -DPIC -o .libs/mpoly.o g++ -DHAVE_CONFIG_H -I. -I. -I.. -Di386 -DLINUX -Wall -g -O3 -MT mpoly.lo -MD -MP -MF .deps/mpoly.Tpo -c mpoly.cpp -o mpoly.o >/dev/null 2> &1 if /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -Di386 -DLINUX -Wall -g -O3 -MT gc.lo -MD -MP -MF ".deps/ gc.Tpo" -c -o gc.lo gc.cpp; \ then mv -f ".deps/gc.Tpo" ".deps/gc.Plo"; else rm -f ".deps/gc.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I.. -Di386 -DLINUX -Wall -g -O3 -MT gc.lo -MD -MP -MF .deps/gc.Tpo -c gc.cpp -DPIC -o .libs/gc.o g++ -DHAVE_CONFIG_H -I. -I. -I.. -Di386 -DLINUX -Wall -g -O3 -MT gc.lo -MD -MP -MF .deps/gc.Tpo -c gc.cpp -o gc.o >/dev/null 2>&1 if /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -Di386 -DLINUX -Wall -g -O3 -MT diagnostics.lo -MD -MP -M F ".deps/diagnostics.Tpo" -c -o diagnostics.lo diagnostics.cpp; \ then mv -f ".deps/diagnostics.Tpo" ".deps/diagnostics.Plo"; else rm -f ".deps/diagnostics.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I.. -Di386 -DLINUX -Wall -g -O3 -MT diagnostics.lo -MD -MP -MF .deps/diagnostics.Tpo -c diagnostics.cpp -DPIC -o .libs/diagnostics.o g++ -DHAVE_CONFIG_H -I. -I. -I.. -Di386 -DLINUX -Wall -g -O3 -MT diagnostics.lo -MD -MP -MF .deps/diagnostics.Tpo -c diagnostics.cpp -o dia gnostics.o >/dev/null 2>&1 if /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -Di386 -DLINUX -Wall -g -O3 -MT arb.lo -MD -MP -MF ".deps /arb.Tpo" -c -o arb.lo arb.cpp; \ then mv -f ".deps/arb.Tpo" ".deps/arb.Plo"; else rm -f ".deps/arb.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I.. -Di386 -DLINUX -Wall -g -O3 -MT arb.lo -MD -MP -MF .deps/arb.Tpo -c arb.cpp -DPIC -o .libs/arb.o g++ -DHAVE_CONFIG_H -I. -I. -I.. -Di386 -DLINUX -Wall -g -O3 -MT arb.lo -MD -MP -MF .deps/arb.Tpo -c arb.cpp -o arb.o >/dev/null 2>&1 if /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -Di386 -DLINUX -Wall -g -O3 -MT reals.lo -MD -MP -MF ".de ps/reals.Tpo" -c -o reals.lo reals.cpp; \ then mv -f ".deps/reals.Tpo" ".deps/reals.Plo"; else rm -f ".deps/reals.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I.. -Di386 -DLINUX -Wall -g -O3 -MT reals.lo -MD -MP -MF .deps/reals.Tpo -c reals.cpp -DPIC -o .libs/reals.o In file included from reals.cpp:59: /usr/include/ieeefp.h:185: error: previous declaration of `int isnan(double)' with C++ linkage /usr/include/math.h:125: error: conflicts with new declaration with C linkage /usr/include/ieeefp.h:186: error: previous declaration of `int isinf(double)' with C++ linkage /usr/include/math.h:126: error: conflicts with new declaration with C linkage /usr/include/ieeefp.h:187: error: previous declaration of `int finite(double)' with C++ linkage /usr/include/math.h:127: error: conflicts with new declaration with C linkage /usr/include/ieeefp.h:191: error: previous declaration of `int isnanf(float)' with C++ linkage /usr/include/math.h:240: error: conflicts with new declaration with C linkage /usr/include/ieeefp.h:192: error: previous declaration of `int isinff(float)' with C++ linkage /usr/include/math.h:241: error: conflicts with new declaration with C linkage /usr/include/ieeefp.h:193: error: previous declaration of `int finitef(float)' with C++ linkage /usr/include/math.h:242: error: conflicts with new declaration with C linkage make[2]: *** [reals.lo] Error 1 make[2]: Leaving directory `/cygdrive/c/user/michael/polyml/libpolyml' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/cygdrive/c/user/michael/polyml' make: *** [all] Error 2 --------------------------------------------------------------------------- On Linux (Mandrake 10.1) the CVS version of PolyML works fine. Regards, Michael Nedzelsky

2 1

Poly/ML version 5 beta
by David.Matthews＠prolingua.co.uk 10 Nov '06

10 Nov '06

Thanks to some financial support from the Verisoft project and TUM I've been working through the summer on an updated version of the Poly/ML run-time system and a new code-generator for the AMD 64-bit architecture. The major new features are: Support for stand-alone binaries Support for additional platforms: AMD64, Intel Macs, Cygwin No artificial limits on size of heaps or saved image Uses standard GNU tools for building Fixed address mmap and trap-handling removed This comes at one significant cost: the persistent store system that has been a feature of Poly/ML almost since the beginning has been removed. The reason for this is that to be effective the persistent store needed to be able to reload a database at the same address every time but that could conflict with other libraries and result in seg faults. Rather than constantly adjust the location of the database with each new kernel release I decided to make the leap and change to making stand-alone binaries. This achieves much the same as the persistent store but without the complications. This version is currently only available by cvs from sourceforge and is a beta release. Full details and example code showing how to export a function and build an application can be found in http://www.polyml.org/Version5Beta.html . Makarius has been testing this with Isabelle and after some bug fixes it all seems to work. I would like to get some more feedback before making a final release but I'm aiming for a release in about a month. David.

2 3

← Newer
1
...
59
60
61
62
63
64
65
...
72
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Poly/ML