bug#258: [22.2]: visiting boost_1_35_0.tar.bz2 causes an error

[Marshall, Simon]

In GNU Emacs 22.2.1 (sparc-sun-solaris2.8, Motif Version 2.1.0)
 of 2008-03-28 on risksun2
Windowing system distributor `Hummingbird Ltd.', version 11.0.100015
configured using `configure  '--x-includes=/usr/openwin/include:/usr/dt/include:/usr/local/include:/usr/local/X11/include' '--x-libraries=/usr/openwin/lib:/usr/dt/lib:/usr/local/lib:/usr/local/X11/lib' '--with-x-toolkit=motif''

This report is going to be annoying, because http://downloads.sourceforge.net/boost/boost_1_35_0.tar.bz2?modtime=1206795398&big_mirror=0 is a 22M file.  Sorry.  This also applies to 22.1.

If I download the file, then visiting it under emacs -Q gives me:

Debugger entered--Lisp error: (args-out-of-range -256589311 -256588799)
  buffer-substring(-256589311 -256588799)
  (tar-header-block-tokenize (buffer-substring pos (+ pos 512)))
  (setq tokens (tar-header-block-tokenize (buffer-substring pos ...)))
  (eq (quote empty-tar-block) (setq tokens (tar-header-block-tokenize ...)))
  (not (eq (quote empty-tar-block) (setq tokens ...)))
  (and (<= (+ pos 512) (point-max)) (not (eq ... ...)))
  (while (and (<= ... ...) (not ...)) (setq pos (+ pos 512)) (progress-reporter-update progress-reporter pos) (if (memq ... ...) (setq pos ...)) (let (...) (if ... ...) (push ... result) (and ... ... ...)))

  (let* ((result ...) (pos ...) (progress-reporter ...) tokens) (while (and ... ...) (setq pos ...) (progress-reporter-update progress-reporter pos) (if ... ...) (let ... ... ... ...)) (make-local-variable (quote tar-parse-info)) (setq tar-parse-info (nreverse result)) (if (eq tokens ...) (progress-reporter-done progress-reporter) (message "Warning: premature EOF parsing tar file")))

  (let ((modified ...)) (set-buffer-multibyte nil) (let* (... ... ... tokens) (while ... ... ... ... ...) (make-local-variable ...) (setq tar-parse-info ...) (if ... ... ...)) (set-buffer-multibyte default-enable-multibyte-characters) (goto-char (point-min)) (let (...) (let ... ...) (narrow-to-region ... ...) (set ... ...) (goto-char ...) (restore-buffer-modified-p modified)))

  tar-summarize-buffer()
  tar-mode()
  set-auto-mode-0(tar-mode nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer boost_1_35_0.tar.bz2> "~/ftp/boost_1_35_0.tar.bz2" nil nil "~/ftp/boost_1_35_0.tar.bz2" (1855815 71344173))

  find-file-noselect("/homedev/marshals/ftp/boost_1_35_0.tar.bz2" nil nil nil)
  find-file("/homedev/marshals/ftp/boost_1_35_0.tar.bz2")
  dired-advertised-find-file()
  call-interactively(dired-advertised-find-file)

The transition of pos to a negative value happens here in tar-summarize-buffer:

          (and (null (tar-header-link-type tokens))
               (> size 0)
               (setq pos
                     (+ pos 512 (ash (ash (1- size) -9) 9)) ; this works
                                        ;(+ pos (+ size (- 512 (rem (1- size) 512)))) ; this doesn't
                     ))

After many iterations of the enclosing loop, but before the above form, pos=49390081 and size=230891239. 
After the above form, pos=-256589311.

The dubious value of size has come from this value of tokens in the enclosing loop:

["boost_1_35_0/doc/html/boost/xpressive/op/insert/result_This(Cont,It,Size,Value),typename disable_if" 17363925 16815366 6377612 230891239 (1040640 53316) 548 nil "" nil nil nil 0 0]

If it is any help, the value of tokens in the previous iteration of the loop is:

[././@LongLink 0 0 0 151 (0 0) 4530 28  t  root 0 0]

If it is any help, there are no files of size 230891239 in the tar.
Solaris "tar -tf" does list many @LongLink files, whereas GNU "tar -tf" does not. 
Solaris tar extracts a file named "boost_1_35_0/doc/html/boost/xpressive/op/insert/result_This(Cont,It,Value),typename disable_if_ mpl_", whereas GNU tar extracts it as "boost_1_35_0/doc/html/boost/xpressive/op/insert/result_This(Cont,It,Value),typename disable_if_ mpl__or__ is_integral_ UNCVREF(It)_,is_same_ UNCVREF(It),UNCVREF(Value)_ _ ___type__id1001524.html", ie, Solaris tar truncates the file name (not file contents).  Emacs tar-mode apparently truncates the file name further.

So it is an "unusual" tar.  There is no difference between the download site's gzip and bzip tars.

I'm guessing that it is a valid tar though.  Emacs should be able to parse it or fail gracefully.

Simon.

"Misys" is the trade name for Misys plc (registered in England and Wales). Registration Number: 01360027. Registered office: Burleigh House, Chapel Oak, Salford Priors, Evesham WR11 8SP. For a list of Misys group operating companies please go to http://www.misys.com/html/about_us/group_operating_companies/. This email and any attachments have been scanned for known viruses using multiple scanners.

 

We believe that this email and any attachments are virus free, however the recipient must take full responsibility for virus checking. This email message is intended for the named recipient only. It may be privileged and/or confidential. If you are not the named recipient of this email please notify us immediately and do not copy it or use it for any purpose, nor disclose its contents to any other person. This email does not constitute the commencement of legal relations between you and Misys plc. Please refer to the executed contract between you and the relevant member of the Misys group for the identity of the contracting party with which you are dealing.