The Scilab port works Ok on 6.2-stable and xorg 7.2. Starting Scilab 4.1.1 in 7.0-current SMP exits. Debug reveals a corrupt stack. This looks similar to another panic reported on the mailing list which reports a corrupt stack. Fix: Unknown How-To-Repeat: In 7.0-current, run scilab. # scilab -debug GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... (gdb) r Starting program: /usr/local/lib/scilab/bin/scilex Program received signal SIGSEGV, Segmentation fault. 0x28d1ce6a in _XtBindActions () from /usr/local/lib/libXt.so.6 (gdb) bt #0 0x28d1ce6a in _XtBindActions () from /usr/local/lib/libXt.so.6 #1 0x28d26c3c in _XtInstallTranslations () from /usr/local/lib/libXt.so.6 #2 0x28d07728 in RealizeWidget () from /usr/local/lib/libXt.so.6 #3 0x00000000 in ?? () #4 0xbfbfdb2c in ?? () #5 0x28d33678 in __JCR_LIST__ () from /usr/local/lib/libXt.so.6 #6 0x0000015b in ?? () #7 0x00000018 in ?? () #8 0xbfbfdb68 in ?? () #9 0x28d0282a in XtMoveWidget () from /usr/local/lib/libXt.so.6 Previous frame inner to this frame (corrupt stack?)
Responsible Changed From-To: freebsd-bugs->freebsd-ports-bugs Initially this more looks like an port issue itself, given the information shown in the PR (all references are to /usr/local/ stuff which is not from the source tree). Reassign to Ports team.
I reconfigured the Hp Pavillion dv6000 to dual boot 6.2-stable and 7.0-current. The problem exists on 7.0-current, but, NOT 6.2-stable. In each, I did install 6.2 from the CD, no X, cvsup-without-gui cvsup [stable|current] and ports make/install iaw src/Makefile install ports net/cvsup x11/xorg sysutils/915resolution math/scilab I have included a script from the session on each, -current first, followed by -stable. The environment variables are the same on -current and -stable. tomdean ####################################################################### Script started on Tue Sep 11 13:33:59 2007 > uname -a FreeBSD dv6000.tddhome 7.0-CURRENT FreeBSD 7.0-CURRENT #0: \ Mon Sep 10 08:30:35 PDT 2007 \ root@dv6000.tddhome:/scratch/obj/usr/usr/src/sys/GENERIC i386 > df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad4s2a 1012974 188932 743006 20% / devfs 1 1 0 100% /dev /dev/ad4s2e 4058062 16 3733402 0% /tmp /dev/ad4s2f 17261300 2325004 13555392 15% /usr /dev/ad4s2d 4058062 16686 3716732 0% /var /dev/ad4s3d 30462636 12 28025614 0% /usr/home /dev/ad4s3e 5069338 2335136 2328656 50% /usr/ports /dev/ad4s4d 54897426 3038530 47467102 6% /scratch > scilab -debug /usr/local/bin/scilab: /usr/local/lib/scilab/pvm3/lib/pvmgetarch: not found GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... (gdb) r Starting program: /usr/local/lib/scilab/bin/scilex Program received signal SIGSEGV, Segmentation fault. 0x28ceee6a in _XtBindActions () from /usr/local/lib/libXt.so.6 (gdb) bt #0 0x28ceee6a in _XtBindActions () from /usr/local/lib/libXt.so.6 #1 0x28cf8c3c in _XtInstallTranslations () from /usr/local/lib/libXt.so.6 #2 0x28cd9728 in RealizeWidget () from /usr/local/lib/libXt.so.6 #3 0x00000000 in ?? () #4 0xbfbfdf5c in ?? () #5 0x28d05678 in __JCR_LIST__ () from /usr/local/lib/libXt.so.6 #6 0x0000015b in ?? () #7 0x00000018 in ?? () #8 0xbfbfdf98 in ?? () #9 0x28cd482a in XtMoveWidget () from /usr/local/lib/libXt.so.6 Previous frame inner to this frame (corrupt stack?) (gdb) c Continuing. Program exited normally. (gdb) quit > exit Script done on Tue Sep 11 13:34:35 2007 ####################################################################### Script started on Tue Sep 11 13:46:54 2007 > uname -a FreeBSD dv6000.tddhome 6.2-STABLE FreeBSD 6.2-STABLE #0: \ Mon Sep 10 11:12:02 PDT 2007 \ root@dv6000.tddhome:/scratch/obj/usr/usr/src/sys/SMP i386 > df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad4s1a 1012974 63338 868600 7% / devfs 1 1 0 100% /dev /dev/ad4s4d 54897426 3038530 47467102 6% /scratch /dev/ad4s1e 4058062 14 3733404 0% /tmp /dev/ad4s1f 17261268 2025356 13855012 13% /usr /dev/ad4s3d 30462636 18 28025608 0% /usr/home /dev/ad4s3e 5069338 2335136 2328656 50% /usr/ports /dev/ad4s1d 4058062 13448 3719970 0% /var /dev/ad4s2a 1012974 188932 743006 20% /mnt > scilab -debug /usr/local/bin/scilab: /usr/local/lib/scilab/pvm3/lib/pvmgetarch: not found GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... (gdb) r Starting program: /usr/local/lib/scilab/bin/scilex Program exited normally. (gdb) quit > exit exit Script done on Tue Sep 11 13:47:30 2007
I believe we may have a compiler problem with gcc42. I had a problem with scilab under both -stable and -current. I installed the port with the default make files. I saw no errors during build/install. Scilab failed at run time. ports/116378 and earlier kern/116166 which was changed to ports. Math/scilab uses math/lapack and math/blas and builds everything with gcc42 and gfortran42. All three ports were up-to-date as of yesterday. Running -stable, # uname -a FreeBSD dv6000.tddhome 6.2-STABLE FreeBSD 6.2-STABLE #2: \ Sat Sep 15 11:31:41 PDT 2007 \ root@dv6000.tddhome:/scratch/obj/usr/usr/src/sys/SMP i386 I deinstalled scilab, blas, and, lapack. I rebuilt them with the default system compilers, g77 and cc. The problem went away. Scilab uses two gfortran specific calls in routines/os_specific/getarg.c. Fixing these and changing the makefiles fixed the problem. Scilab. Changed Makefile to use g77, cc, c++ USE_FORTRAN= g77 CC=cc CXX=c++ F77=f77 build lapack with g77 USE_FORTRAN=g77 build blas with g77 USE_FORTRAN=g77 Removed gfortran from /scratch/obj/ports/usr/ports/math/scilab/work/scilab-4.1.1/routines/os_specific/getarg.c By using the default call in the #if..else statement. tomdean
Steve Kargl <sgk@troutmask.apl.washington.edu> pointed out the lapack problem. http://www.netlib.org/lapack/faq.html#1.25 1.25) Problems compiling dlamch.f? The routine dlamch.f (and its dependent subroutines dlamc1, dlamc2, dlamc3, dlamc4, dlamc5) MUST be compiled without optimization. If you downloaded the entire lapack distribution this will be taken care of by the LAPACK/SRC/Makefile. However, if you downloaded a specific LAPACK routine plus dependencies, you need to take care that slamch.f (if you downloaded a single precision real or single precision complex routine) or dlamch.f (if you downloaded a double precision real or double precision complex routine) has been included. # cd /usr/ports/math/lapack # make clean # script 200709152133.build # make # exit # grep -n lamc 200709152133.build 18:( cd INSTALL; make; ./testlsame; ./testslamch; ./testdlamch; ./testsecond; ./testdsecnd; cp lsame.f ../BLAS/SRC/; cp lsame.f ../SRC; cp slamch.f ../SRC/; cp dlamch.f ../SRC/; cp second.f ../SRC/; cp dsecnd.f ../SRC/; cp etime_.c ../SRC/ ) 22:gfortran42 -c slamch.f 23:gfortran42 -O -c slamchtst.f 24:gfortran42 -o testslamch slamch.o lsame.o slamchtst.o 25:gfortran42 -c dlamch.f 26:gfortran42 -O -c dlamchtst.f 27:gfortran42 -o testdlamch dlamch.o lsame.o dlamchtst.o 370:gfortran42 -O -c slamch.f 1013:gfortran42 -O -c dlamch.f 1664:gfortran42 -pg -O -o slamch.po -c slamch.f 2307:gfortran42 -pg -O -o dlamch.po -c dlamch.f 2958:gfortran42 -fpic -DPIC -O -o slamch.So -c slamch.f 3601:gfortran42 -fpic -DPIC -O -o dlamch.So -c dlamch.f slamch.f and dlamch.f are compiled three times. One time without optimizaton and two times WITH optimization! tomdean
State Changed From-To: open->closed
State Changed From-To: closed->open Reopen (wrong keyboard shortcut)
Responsible Changed From-To: freebsd-ports-bugs->maho Maoh@ is the maintainer of math/lapack, maybe he can say something about this issue. http://www.netlib.org/lapack/faq.html#1.25
From: edwin@FreeBSD.org Subject: Re: ports/116166: math/scilab: Scilab 4.1.1 exits with corrupt stack. Date: Sun, 23 Sep 2007 07:21:18 +0000 (GMT) > Synopsis: math/scilab: Scilab 4.1.1 exits with corrupt stack. > > State-Changed-From-To: closed->open > State-Changed-By: edwin > State-Changed-When: Sun Sep 23 07:20:11 UTC 2007 > State-Changed-Why: > Reopen (wrong keyboard shortcut) > > > Responsible-Changed-From-To: freebsd-ports-bugs->maho > Responsible-Changed-By: edwin > Responsible-Changed-When: Sun Sep 23 07:20:11 UTC 2007 > Responsible-Changed-Why: > Maoh@ is the maintainer of math/lapack, maybe he can say something > about this issue. > > http://www.netlib.org/lapack/faq.html#1.25 > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=116166 Yes, I'm aware of this by recent e-mail by bf. I think we need to rewrite Makefile and update to lapack 3.1 at the same time. thanks, -- Nakata Maho (maho@FreeBSD.org)
State Changed From-To: open->closed Submitter's request. This PR should be closed and open as a new PR. ports/116777: The math/scilab port fails in demos->signal->bode is a new PR with a more scilab specific complaint.