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: |
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
comment:2 in reply to: ↑ description Changed 6 years ago by
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
- Branch set to u/gagern/ticket/17940
comment:4 Changed 6 years ago by
- Commit set to 381899884cca9c1d4c1654cb41e3b3d0eeac553c
- Status changed from new to needs_review
Setting the locale to C works as expected.
New commits:
3818998 | Trac #17940: Execute JMol in C locale.
|
comment:5 follow-up: ↓ 6 Changed 6 years ago by
- 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
- 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: ↓ 8 Changed 6 years ago by
comment:8 in reply to: ↑ 7 Changed 6 years ago by
- Keywords strange added
comment:9 Changed 6 years ago by
- Branch changed from u/gagern/ticket/17940 to 381899884cca9c1d4c1654cb41e3b3d0eeac553c
- Resolution set to fixed
- Status changed from positive_review to closed
Works for me. Can you post your strace output? Can PIL open a PNG at all on your system?