FS#7281 - bc have a problem with parameters when using with MATH LIB
Attached to Project:
Arch Linux
Opened by Gerhard Brauer (GerBra) - Saturday, 26 May 2007, 22:02 GMT
Last edited by Pierre Schmitz (Pierre) - Tuesday, 29 May 2007, 14:56 GMT
Opened by Gerhard Brauer (GerBra) - Saturday, 26 May 2007, 22:02 GMT
Last edited by Pierre Schmitz (Pierre) - Tuesday, 29 May 2007, 14:56 GMT
|
Details
Hello,
first excuse my english, I'm not a native speaker. If parsing expressions to bc when using the MATH LIB (-l) then bc seems not to evaluate these expression. For example: echo "1+1" | bc 2 echo "1+1" | bc -l does nothing. We found this discussioned an example in the man page: echo "scale=3000; 4*a(1)" | bc -l This doesn't work like expected. I tried this on an Debian system and there it works (same bc version 1.06) We could reproduce this also when starting bc alone: bc -l scale=300 4*a(1) 3.14159265358979323844 Here bc doesn't respect the scale value, but when using command history (cursor up) scale=300 4*a(1) 3.141592653589793238462643383279502884197169399375105820974944592307\ 81640628620899862803482534211706798214808651328230664709384460955058\ 22317253594081284811174502841027019385211055596446229489549303819644\ 28810975665933446128475648233786783165271201909145648566923460348610\ 454326648213393607260249141272 bc is version 1.06-3 We have tested this also on an Arch64 system. There it works. Seems only a problem on i686. There is also a hint for a bug searching when starting the command with strace (all traces are shortened): /bin/echo "1+1" | strace /usr/bin/bc read(0, "1+1\n", 8192) = 4 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 3), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f68000 write(1, "2\n", 22 ) = 2 read(0, "", 8192) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfc5f428) = -1 EINVAL (Invalid argument) exit_group(0) = ? Process 6475 detached /bin/echo "1+1" | strace /usr/bin/bc -l read(0, "1+1\n", 8192) = 4 read(0, "", 8192) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf8b0878) = -1 EINVAL (Invalid argument) exit_group(0) = ? Process 6481 detached Look at the additional read when running with MATH LIB and the missing fstat64 call. |
This task depends upon
Closed by Pierre Schmitz (Pierre)
Tuesday, 29 May 2007, 14:56 GMT
Reason for closing: Fixed
Additional comments about closing: use -O3 instead of -O0 to speed up bc for x86_64 and fix bug #7281 for i686
Tuesday, 29 May 2007, 14:56 GMT
Reason for closing: Fixed
Additional comments about closing: use -O3 instead of -O0 to speed up bc for x86_64 and fix bug #7281 for i686
PS: I have up2date i686, works for me with both "-march=i686 -O2" and "-mtune=prescott -O3"
I always get an segfault when i use any optimization in CFLAGS.
Using -O0 then it is ok.
Here's my "debugging"
CFLAGS="-march=i686 -O2 -g -ggdb"
gdb ./src/bc-1.06/bc/bc
---------
NU gdb 6.6
Copyright (C) 2006 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 "i686-pc-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) run -l
Starting program: /tmp/bc/src/bc-1.06/bc/bc -l
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
1+1
Program received signal SIGSEGV, Segmentation fault.
0x0804d911 in addbyte (byte=49 '1') at load.c:78
78 f->f_body[pc] = byte;
-------------
I have an AMD Sempron(tm) 2400+
For myself i could not provide the binary somewhere.
Attaching it here in comment by "Atatch a file(max 2MiB" does this work?
I got the segfault only when self compiling bc from abs.
The binary packet from [current] does not segfault, it behave like i report in initial bug report.
I must correct my statement that no optimization flag work.
CFLAGS="-march=i686 -O3 -pipe" produce a binray that works correctly.
All other (and so the makepkg.conf default CFLAGS="-march=i686 -O2 -pipe") optimization levels produce the segfault.
I've checked my RAM overnight, no problem.
And here the mysterious:
I put this CFLAGS statement in PKGBUILD.
When starting with -O3, then i could later use any of the other optimization flags when i run makepg -f. It seems when make use his formerly cached values from .configure, then each build binary in ./pkg/usr/bin works without segfaulting.
But when starting a fresh build, without ./pkd and ./src, then only -O3 produce a working bc binary. All other -O Flags except -O0 produce a segfaulting bc.
Strange, huh?
It seems that the source and/or additional libs have some ABI problems when running/compiling under different cpu types.
My suggestion is to rebuild this package in [current] either with -O0 or with -O3.
When you look at the PKGBUILD there is still a seperat CFLAGS statement when building for x86_64, that is -O0.
But -O0 reduce the speed of calculating in bc with MATH_LIB dramatically.
For ex.
time echo "scale=3000; 4*a(1)" | ./pkg/usr/bin/bc -l
with -O0: 0m40.527s
with -O3: 0m17.799s
I tried on my Athlon some other relevant -mtune options, but only -O3 or -O0 works.
I'm not a programmer but i think by myself that upstream have to change some things to respect different ABI changes.
And maybe we get nearly problems when gcc 4.2 arrives in [current].
So i would prefer a change in PKGBUILD:
--------------
build() {
[ "${CARCH}" = "x86_64" ] && CFLAGS="-march=x86-64 -O0 -pipe"
[ "${CARCH}" = "i686" ] && CFLAGS="-march=i686 -O3 -mtune=generic -pipe"
cd ${startdir}/src/${pkgname}-${pkgver}
...
--------------
And so a rebuild/change in [current] to fix initial problem.
I don't know if -O0 is a must for x86_64, maybe we could switch also to -O3 for this architecture.
As ArchLinux only provide packages for i686 (and the pendant 64Bit) i think an optimization level with -O3 isn't to much aggressive.
Also try this on x86_64 - this can possibly let us dispose from that annoying line '[ "${CARCH}" = "x86_64" ] && CFLAGS="-march=x86-64 -O0 -pipe"' in PKGBUILD.
How to apply: if patch is in "./src" and you are in "./src/bc-1.06" then run "patch -p1 <../longint.patch"
I put it in PKGBUILD, it applied correctly.
I build another binary with debugging code for gdb
and i got the segault at the same code line as on my first test, without your patch.
I have no possibility to test this for this architecture myself,
but i could ask a friend to try it first with -O2 without than with your patch.