[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 ?? ()
--- 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
+Build-Depends: e2fslibs-dev
  d546fd92dfa16255e062fa8505a5b8d4 39440 quik_2.0e.orig.tar.gz
  1dfe661d5d33f6d0219da351b364d09d 4702 quik_2.0e-0.1.diff.gz

Reply to: