Opened 6 years ago

Closed 6 years ago

#17940 closed defect (fixed)

IOError: cannot identify image file

Reported by: gagern Owned by:
Priority: major Milestone: sage-6.6
Component: user interface Keywords: strange
Cc: vbraun Merged in:
Authors: Martin von Gagern Reviewers: Volker Braun
Report Upstream: Workaround found; Bug reported upstream. Work issues:
Branch: 3818998 (Commits, GitHub, GitLab) Commit: 381899884cca9c1d4c1654cb41e3b3d0eeac553c
Dependencies: Stopgaps:

Status badges

Description

With Sage 6.6 beta 3 and using Sage Notebook I get a backtrace when I want to see a sphere:

sage: sphere()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "_sage_input_3.py", line 10, in <module>
    exec compile(u'open("___code___.py","w").write("# -*- coding: utf-8 -*-\\n" + _support_.preparse_worksheet_cell(base64.b64decode("c3BoZXJlKCk="),globals())+"\\n"); execfile(os.path.abspath("___code___.py"))
  File "", line 1, in <module>
    
  File "/tmp/tmpWqCNEl/___code___.py", line 2, in <module>
    exec compile(u'sphere()
  File "", line 1, in <module>
    
  File "sage/local/lib/python2.7/site-packages/sage/repl/rich_output/display_manager.py", line 716, in displayhook
    return self._backend.displayhook(plain_text, rich_output)
  File "sage/local/lib/python2.7/site-packages/sage/repl/rich_output/backend_base.py", line 432, in displayhook
    return self.display_immediately(plain_text, rich_output)
  File "sage/local/lib/python2.7/site-packages/sage/repl/rich_output/backend_sagenb.py", line 361, in display_immediately
    rich_output.embed()
  File "sage/local/lib/python2.7/site-packages/sage/repl/rich_output/backend_sagenb.py", line 258, in embed
    self.save_preview()
  File "sage/local/lib/python2.7/site-packages/sage/repl/rich_output/backend_sagenb.py", line 237, in save_preview
    self.preview_png.save_as(self.preview_filename())
  File "sage/misc/cachefunc.pyx", line 2209, in sage.misc.cachefunc.CachedMethodCallerNoArgs.__call__ (build/cythonized/sage/misc/cachefunc.c:13699)
  File "sage/local/lib/python2.7/site-packages/sage/repl/rich_output/backend_sagenb.py", line 189, in preview_filename
    directory, filename = os.path.split(self._base_filename())
  File "sage/misc/cachefunc.pyx", line 2209, in sage.misc.cachefunc.CachedMethodCallerNoArgs.__call__ (build/cythonized/sage/misc/cachefunc.c:13699)
  File "sage/local/lib/python2.7/site-packages/sage/repl/rich_output/backend_sagenb.py", line 147, in _base_filename
    filename = self.sagenb_launch_script_filename()
  File "sage/misc/cachefunc.pyx", line 2209, in sage.misc.cachefunc.CachedMethodCallerNoArgs.__call__ (build/cythonized/sage/misc/cachefunc.c:13699)
  File "sage/local/lib/python2.7/site-packages/sage/repl/rich_output/backend_sagenb.py", line 122, in sagenb_launch_script_filename
    width, height = PIL.Image.open(StringIO(self.preview_png.get())).size
  File "build/bdist.linux-x86_64/egg/PIL/Image.py", line 2006, in open
IOError: cannot identify image file

Using strace I can see access to some preview.png and looking at that file I notice that it appears to be a regular PNG, concatenated with a Jmol script. So apparently two outputs ended up in the same data stream. This is likely a consequence of #17234.

Change History (9)

comment:1 Changed 6 years ago by vbraun

Works for me. Can you post your strace output? Can PIL open a PNG at all on your system?

comment:2 in reply to: ↑ description Changed 6 years ago by gagern

Replying to gagern:

Using strace I can see access to some preview.png and looking at that file I notice that it appears to be a regular PNG, concatenated with a Jmol script. So apparently two outputs ended up in the same data stream. This is likely a consequence of #17234.

It seems I was misled: apparently JMol attaching its script to the generated PNG is normal behavior. The PNG file is apparently broken at some other point. Looking at the PNG chunks as reported by the pngchunks tool, I see that the IDAT chunk appears to be off by one byte. The chunk before that is an iTXt chunk stating the creation date. It does so in a locale-dependent manner, and in my case that means using the German abbreviation for March, which is Mär. So I'd say JMol is counting UTF-16 code units when it should be counting UTF-8 code units. This is a bug in JMol, and probably can be reproduced at least this month by using a German locale.

I'll try to see whether we can work around this issue by forcing the locale to C, like LC_ALL=C or some Java-specific analogon to this.

comment:3 Changed 6 years ago by gagern

  • Branch set to u/gagern/ticket/17940

comment:4 Changed 6 years ago by gagern

  • Authors set to Martin von Gagern
  • Commit set to 381899884cca9c1d4c1654cb41e3b3d0eeac553c
  • Status changed from new to needs_review

Setting the locale to C works as expected.


New commits:

3818998Trac #17940: Execute JMol in C locale.

comment:5 follow-up: Changed 6 years ago by vbraun

  • Reviewers set to Volker Braun
  • Status changed from needs_review to positive_review

Good detective job ;-)

Did you report it upstream?

comment:6 in reply to: ↑ 5 Changed 6 years ago by gagern

  • Report Upstream changed from N/A to Workaround found; Bug reported upstream.

Replying to vbraun:

Did you report it upstream?

Did so now: https://sourceforge.net/p/jmol/bugs/570/

comment:7 follow-up: Changed 6 years ago by jdemeyer

A bug which happens only in March :-)

This should be added to the "strange bug list" together with #10609 and #12221.

comment:8 in reply to: ↑ 7 Changed 6 years ago by gagern

  • Keywords strange added

Replying to jdemeyer:

This should be added to the "strange bug list" together with #10609 and #12221.

Done here, shoudl I do the others as well?

comment:9 Changed 6 years ago by vbraun

  • Branch changed from u/gagern/ticket/17940 to 381899884cca9c1d4c1654cb41e3b3d0eeac553c
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.