[techtalk] Adobe Acrobat help needed (fwd)

[Laurel Fan]

Excerpts from linuxchix: 17-May-100 Re: [techtalk] Adobe Acroba.. by
Lynn Kuhlman at eskimo.com 
> acroread ../../Source/ATM/Extra/Edge/FileCore.cpp:322:CTBool, CTFile:
> Write(const void *, unsigned int): Assertion 'nWritten == nCount' failed.
> Abort

Looks like an assert() failed[1].  If acroread was open source, I (or anyone
else so inclined) would be able to look at line 322 of the file
../../Source/AIM/Extra/Edge/FileCore.cpp and see what would cause this.
There are several open source pdf viewers, xpdf, which was mentioned before,
and gv (which reads pdf and postscript).

Making a wild guess, it appears that it is unable to write a file.  There
are three kinds of file a program usually writes: config files, output,
and temp files.  Since you're probably not trying to output yet, this
eliminates it to config files and temp files.  Acroread seems to have
a config file ~/.acrorc (the ~ means your home directory, if you didn't
know).  Check to make sure that this is writable by the user.  Temp files
are usually in /tmp.  Make sure that the user is allowed to create files
in /tmp.

Also, check for disk space on the partitions where /tmp and your home
directory are.  If the disk is more than 90% and less than 100% full,
root will be allowed to write to it, but users usually will not.

If it's none of these problems, and you have some reason to want to
use acroread instead of one of the non-proprietary solutions, strace
it (run 'strace acroread'), and post the last 20 lines or so of that.
strace traces system calls (such as writing files), so if we can see
what it's trying to do before it dies, we might be able to figure out
what exactly is wrong.

[1] assert() is a C function generally used for debugging.  While writing
a program, one often makes assumptions on what should be true at some
point based on what the program does before that point.  A problem arises
when your assumptions are wrong, either because you changed the code,
or it wasn't right in the first place.  The error could also propagate
pretty far before causing a crash or data loss, making it annoying to
debug.
It's a good idea to put your assumptions in asserts, for example:
  assert(number_of_open_files >= 0);
If number_of_open_files is, in fact, not greater than or equal to 0 when
the program gets to this line, it will print an error message, like
the one above, telling you exactly what and where failed, and exit.
Then, you go look at the code, and figure out why your assumption was
not true and how to fix it.