Hide Forgot
I have only reproduced with crash-4.0-8.12 on RHEL 4 but I don't see any reason why it shouldn't occur in other distributions. Since that version of crash is not in RHEL, I am filling this bug against rawhide although I don't have a rawhide system to repro. crash-4.0.8.12.src.rpm (latest available at http://people.redhat.com/anderson/ at the time of this writing) fails to build if bison and flex are not installed although it doesn't list these packages as build requirements: # rpm -ivh crash-4.0-8.12.src.rpm [...] # rpmbuild -ba /usr/src/redhat/SPECS/crash.spec [...] cc -c -g -O2 -g -DX86 -D_FILE_OFFSET_BITS=64 qemu-load.c ar -rs crashlib.a main.o tools.o global_data.o memory.o filesys.o help.o task.o build_data.o kernel.o test.o gdb_interface.o net.o dev.o alpha.o x86.o ppc.o ia64.o s390.o s390x.o s390dbf.o ppc64.o x86_64.o extensions.o remote.o va_server.o va_server_v1.o symbols.o cmdline.o lkcd_common.o lkcd_v1.o lkcd_v2_v3.o lkcd_v5.o lkcd_v7.o lkcd_v8.o lkcd_fix_mem.o s390_dump.o netdump.o diskdump.o xendump.o lkcd_x86_trace.o unwind_v1.o unwind_v2.o unwind_v3.o unwind_x86_32_64.o xen_hyper.o xen_hyper_command.o xen_hyper_global_data.o xen_hyper_dump_tables.o kvmdump.o qemu.o qemu-load.o ar: creating crashlib.a gcc -g -O2 \ -o `cat mergeobj` libgdb.a \ ../bfd/libbfd.a ../readline/libreadline.a ../opcodes/libopcodes.a ../libiberty/libiberty.a -lm -lncurses ../libiberty/libiberty.a -ldl -rdynamic `cat mergelibs` + make RPMPKG=4.0-8.12 extensions gcc -nostartfiles -shared -rdynamic -o dminfo.so dminfo.c -fPIC -DX86 -D_FILE_OFFSET_BITS=64 gcc -nostartfiles -shared -rdynamic -o echo.so echo.c -fPIC -DX86 -D_FILE_OFFSET_BITS=64 cd libsial && make bison -psial -v -t -d sial.y make[4]: bison: Command not found make[4]: [sial.tab.h] Error 127 (ignored) cc -O3 -g -fPIC -c -o sial_util.o sial_util.c cc -O3 -g -fPIC -c -o sial_node.o sial_node.c cc -O3 -g -fPIC -c -o sial_var.o sial_var.c cc -O3 -g -fPIC -c -o sial_func.o sial_func.c cc -O3 -g -fPIC -c -o sial_str.o sial_str.c cc -O3 -g -fPIC -c -o sial_op.o sial_op.c sial_op.c:5:22: sial.tab.h: No such file or directory [...] + cp extensions/sial.so /var/tmp/crash-root/usr/lib/crash/extensions cp: cannot stat `extensions/sial.so': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.65084 (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.65084 (%install) # up2date bison # rpmbuild -ba /usr/src/redhat/SPECS/crash.spec [...] cc -O3 -g -fPIC -c sial.tab.c flex -L -Psial -t sial.l > lex.sial.c /bin/sh: flex: command not found make[4]: [lex.sial.c] Error 127 (ignored) cc -O3 -g -fPIC -c lex.sial.c flex -Psialpp -t sialpp.l > lex.sialpp.c /bin/sh: flex: command not found make[4]: [lex.sialpp.c] Error 127 (ignored) cc -O3 -g -fPIC -c lex.sialpp.c cc -O3 -g -fPIC -o mkbaseop mkbaseop.c ./mkbaseop > baseops.c cc -O3 -g -fPIC -c baseops.c ar ccurl libsial.a sial_util.o sial_node.o sial_var.o sial_func.o sial_str.o sial_op.o sial_num.o sial_stat.o sial_builtin.o sial_type.o sial_case.o sial_api.o sial_member.o sial_alloc.o sial_define.o sial_input.o sial_print.o sialpp.tab.o sial.tab.o lex.sial.o lex.sialpp.o baseops.o gcc -g -I.. -Ilibsial -I../gdb-6.1/bfd -I../gdb-6.1/include -I../gdb-6.1/gdb -I../gdb-6.1/gdb/config -nostartfiles -shared -rdynamic -o sial.so sial.c -fPIC -DX86 -Llibsial -lsial snap.mk:4: Extraneous text after `else' directive snap.mk:7: Extraneous text after `else' directive snap.mk:7: *** only one `else' per conditional. Stop. make[2]: [snap.so] Error 2 (ignored) + exit 0 Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.7158 + umask 022 + cd /usr/src/redhat/BUILD + cd crash-4.0-8.12 + LANG=C + export LANG + unset DISPLAY + rm -rf /var/tmp/crash-root + mkdir -p /var/tmp/crash-root/usr/bin + make DESTDIR=/var/tmp/crash-root install /usr/bin/install crash /var/tmp/crash-root/usr/bin + mkdir -p /var/tmp/crash-root/usr/share/man/man8 + cp crash.8 /var/tmp/crash-root/usr/share/man/man8/crash.8 + mkdir -p /var/tmp/crash-root/usr/include/crash + cp defs.h /var/tmp/crash-root/usr/include/crash + mkdir -p /var/tmp/crash-root/usr/lib/crash/extensions + cp extensions/sial.so /var/tmp/crash-root/usr/lib/crash/extensions + cp extensions/dminfo.so /var/tmp/crash-root/usr/lib/crash/extensions + cp extensions/snap.so /var/tmp/crash-root/usr/lib/crash/extensions cp: cannot stat `extensions/snap.so': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.7158 (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.7158 (%install) # up2date flex [...] # rpmbuild -ba /usr/src/redhat/SPECS/crash.spec [...this still fails on RHEL 4 because of some Makefile compatilibity problem but that's unrelated...]
> I have only reproduced with crash-4.0-8.12 on RHEL 4 but I don't see any > reason why it shouldn't occur in other distributions. Since that version > of crash is not in RHEL, I am filling this bug against rawhide although > I don't have a rawhide system to repro. Yeah, the extensions are not supported under RHEL or Fedora at all, and so the "make extensions" command does not exist under the %build stanza in the crash.spec file of any of those releases. So there's really no "Product" to file this BZ against, and issues such as these are typically discussed on the crash-utility mailing list: https://www.redhat.com/mailman/listinfo/crash-utility In any case, one of the prime reasons for not supporting extension modules in any release is that I don't want to impose additional build requirements for extension modules that are used by remarkably few people. (Especially the sial module -- although those few that do swear by it, I've never used it...) So I'm not particularly interested in forcing a buildrequires, for bison and flex, although perhaps I can at least tinker with the sial.mk file to verify that the /usr/bin/bison and /usr/bin/flex commands exist, and bail out a little more gracefully. On the other hand, the snap.mk error is a surprise to me, although the module is a new one, and apparently I never tried building it on a RHEL4 machine. It builds fine on RHEL5. Anyway, it looks like a simple fix for that issue. Thanks, Dave
Created attachment 359723 [details] snap.c
Created attachment 359724 [details] snap.mk file to support older make version 3.80
Created attachment 359725 [details] sial.mk to handle lack of /usr/bin/bison & /usr/bin/flex
These 3 files should handle all of the problems: - The sial.mk file just fails the sial.so build more gracefully. - The snap.mk file conforms to the older make version 3.80 restrictions - The snap.c file should recognize the pre-2.6.13 kernel versions that only displayed "System RAM" if it was below 4GB. If you get a chance to verify them, let me know if there's any more problems. Unless I hear otherwise, they will be in the next upstream release. Thanks for the report! Dave
- I confirm the new snap.mk allows snap.so to be built without problem on RHEL4; - The new snap.c still doesn't work for over 4G RAM on RHEL4. While earlier patch as posted in crash-utility list works fine ( https://www.redhat.com/archives/crash-utility/2009-September/msg00008.html ) the new snap.c attached to this bz fails in the same way as the original one as described in that thread; - I haven't checked sial.mk at this time.
I was on PTO today, so I didn't get a chance to see this until now. I don't have a large enough machine to test this on, so can you modify the patched snap.c file to indicate machine_type("X86_64") instead of of machine_type("x86_64") below: verify_paddr(physaddr_t paddr) { int i, ok; if (!machdep->verify_paddr(paddr)) return FALSE; if (!nr_segments) return TRUE; for (i = ok = 0; i < nr_segments; i++) { if ((paddr >= ram_segments[i].start) && (paddr < ram_segments[i].end)) { ok++; break; } } /* * Pre-2.6.13 x86_64 /proc/iomem was restricted to 4GB, * so just accept it. */ if ((paddr >= 0x100000000ULL) && - machine_type("x86_64") && + machine_type("X86_64") && (THIS_KERNEL_VERSION < LINUX(2,6,13))) ok++; if (!ok) { if (CRASHDEBUG(1)) console("reject: %llx\n", (ulonglong)paddr); return FALSE; } return TRUE; } Sorry about that -- and thanks for catching it (again...) I did test the new sial.mk on my RHEL4 box -- the capability of having multiple else directives in a makefile was introduced in make version 3.81, where RHEL4 used version 3.80.
> I did test the new sial.mk on my RHEL4 box -- the capability of having > multiple else directives in a makefile was introduced in make version 3.81, > where RHEL4 used version 3.80. Except that's the *snap.mk* issue... I tested the sial.mk issue by moving /usr/bin/flex and /usr/bin/bison out the way temporarily.
I renamed this bug to make it easier to find. After changing the line as described in comment #7 I was able to capture a 16G vmcore on RHEL 4.
Created attachment 360042 [details] latest working snap.c based on comment #7
All issues have been addressed in 4.0.9-2.fc12: http://koji.fedoraproject.org/koji/buildinfo?buildID=131574
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This has been fixed as per comment 11.