Re: New Quik available
Daniel Jacobowitz wrote:
> I've put an NMU of Quik 2.0e with patches in Incoming - with luck and
> archive maintainers it will be available soon.
>
> I'd appreciate feedback on it. Also, in the postinst is some commented
> out PReP work - is it relevant? If so could someone with more PReP
> knowledge than I complete it?
Thank you for the new quik. Unfortunately, it still segfaulted for me, this has
been a problem for some time.
So I finally got the source and looked into the problem. A backtrace gave the
attached, which indicates resolve_to_dev() is not handling my setup properly,
but I have a somewhat, um, non-standard setup.
I boot from the zip drive, because Debian is on /dev/hdb, so OF can't see it. I
have /boot symlinked to /zip/boot, and /zip is a symlink to /misc/zip which is
automounted; /etc/quik.conf is symlinked to /zip/etc/quik.conf. So
resolve_to_dev is getting confused by the simlink.
The problem is the logic on line 388 of quik.c:
if (*readlinkbuf == '/') {
This is supposed to be true if the simlink is to something in root. It does not
account for the fact that a simlink *from* root also goes to root, even without
the leading /. Instead it executes lines 391-395, which just add / and expand
the name. So line 388 should have something like:
if (*readlinkbuf == '/' || p == buffer+1) {
which I think would indicate that the first word is a simlink (or should it be
q-buffer==1?), so the simlink is from root, and therefore goes to root. (I
don't know if this works, but I am out of time to investigate this. This
subroutine is very hard to read, let alone understand its iterative symlink
resolution procedure, and the lack of commenting and one-letter variable names
don't help...)
My workaround was to symlink /zip to /misc/zip (notice the leading /), so
(*readlinkbuf == '/') is true, and this did not segfault.
Why does this need to be fixed? I understand that not everyone has as
pathalogical a setup as my booting from a symlinked automounted drive, but it
seems there are less pathalogical reasons to simlink from root into a directory
on a different device, and quik should be robust to this, including the missing
leading / in the symlink.
So, it didn't segfault, but it also didn't quite work. I can't get OF to boot
from the zip drive now. It says something about [device:][partno/]path or mm-nn
for blocks, and I give it the quik.conf label (which used to work, I think in
2.0-2), and it says it can't open the filesystem.
If I can get it to work, then I'll try the || p == buffer+1 solution, to see if
that works with a symlink without /.
Oh, this is for a StarMax 3000/160 (=pmac 4400).
Any ideas? Thanks again for the new quik, I hope it works soon! If I get any
more time I'll look into p==1 or other possible solutions.
Finally, a patch to the .dsc file, because I like Build-Depends and wish more
packages had them (even if they don't really do anything yet :-).
-Adam P.
(gdb) run
Starting program: /usr/src/packages/quik-2.0e/quik/quik
Program received signal SIGSEGV, Segmentation fault.
0x10011d0c in strcpy ()
(gdb) backtrace
#0 0x10011d0c in strcpy ()
#1 0x100013a0 in resolve_to_dev (
buffer=0x7ffff3a8 "/zip/misc/zip/misc/zip/misc/zip/misc/zip/misc/zip/misc/zip/misc/zip/misc/zip/misc/zip/misc/zip/misc/zip/misc/zip/misc/zip/misc/zip/misc/zip/misc/zip/misc/zip/misc/zip/misc/zip/misc/zip/misc/zip/misc/z"..., dev=2052)
at quik.c:403
#2 0x69702f6d in ?? ()
#3 0x0 in ?? ()
(gdb)
--- quik_2.0e-0.1.dsc.bak Mon Apr 3 21:27:08 2000
+++ quik_2.0e-0.1.dsc Mon Apr 3 21:28:52 2000
@@ -7,6 +7,7 @@
Maintainer: Hartmut Koptein <koptein@debian.org>
Architecture: powerpc
Standards-Version: 3.0.1.1
+Build-Depends: e2fslibs-dev
Files:
d546fd92dfa16255e062fa8505a5b8d4 39440 quik_2.0e.orig.tar.gz
1dfe661d5d33f6d0219da351b364d09d 4702 quik_2.0e-0.1.diff.gz
Reply to: