After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 698688 - Cage tool makes Gimp to crash
Cage tool makes Gimp to crash
Status: RESOLVED DUPLICATE of bug 688361
Product: GIMP
Classification: Other
Component: Tools
2.8.4
Other Windows
: Normal critical
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2013-04-23 18:18 UTC by F Champigneul
Modified: 2013-04-25 18:02 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description F Champigneul 2013-04-23 18:18:24 UTC
Gimp crashes whenever trying to use the Cage tool (when clicking a second time on the first node in order to close the cage), with the following error message:
"
Microsoft Visual C++ Runtime Library
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information
"

My system is Windows 7 64 bits.
I tried with Gimp 2.8.2 (with the installer that was at the sourceforge website in December 2012), and with 2.8.4 (with the installer at the sourceforge website): in both cases I get this issue. I also tried the "SET GEGL_SWAP=RAM" workaround described in bug 676468 but it doesn't help.

Launching Gimp using the verbose option (gimp-2.8.exe --verbose), I get this in the debug window when trying to use the Cage transform tool:

"
Loading module 'C:\Program Files\GIMP 2\lib\gimp\2.0\modules\libdisplay-filter-lcms.dll'
**
GEGL-gegl-tile-backend-file.c:ERROR:gegl-tile-backend-file.c:957:gegl_tile_backend_file_ensure_exist: assertion failed: (self->i != -1)
"

My windows user profile does contain one non ascii character.
I first reported the issue in bug 676468, but since that bug status was already "resolved", the cause here might be different.
Comment 1 Max Mustermann 2013-04-23 18:31:17 UTC
Is this a revival of bug #675285?

Where did you get your GIMP version from?
Can you please post the output of gimp-2.8 -v ?
Comment 2 Michael Schumacher 2013-04-23 18:40:18 UTC
Works fine for me in 2.8.4 on Windows XP 32 bit.
Comment 3 F Champigneul 2013-04-23 18:42:03 UTC
I downloaded GIMP from the sourceforge website (http://www.gimp.org/downloads/)
on March 25th 2013.

Here is the ouput of "gimp-2.8 -v":

╔diteur d'image GIMP version 2.8.4
git-describe: Unknown, shouldn't happen

utilisation de GEGL version 0.2.0 (compilÚ avec la version 0.2.0)
utilisation de GLib version 2.32.3 (compilÚ avec la version 2.32.3)
utilisation de GdkPixbuf version 2.26.1 (compilÚ avec la version 2.26.1)
utilisation de GTK+ version 2.24.10 (compilÚ avec la version 2.24.10)
utilisation de Pango version 1.30.0 (compilÚ avec la version 1.30.0)
utilisation de Fontconfig version 2.9.0 (compilÚ avec la version 2.9.0)
utilisation de Cairo version 1.10.2 (compilÚ avec la version 1.10.2)
(saisissez n'importe quel caractère pour fermer cette fenêtre)
Comment 5 Eduard Braun 2013-04-23 18:48:14 UTC
I'm facing the same problem with GIMP 2.8.4 on Windows 7 x64. I'm using the official installers by Jernej Simončič.
Setting the environment variable "GEGL_SWAP=RAM" prevents the runtime error in my case.


Output of gimp-2.8 -v:
 GNU Image Manipulation Program Version 2.8.4
 git-describe: Unknown, shouldn't happen

 verwendet GEGL Version 0.2.0 (gebaut gegen Version 0.2.0)
 verwendet GLib Version 2.32.3 (gebaut gegen Version 2.32.3)
 verwendet GdkPixbuf Version 2.26.1 (gebaut gegen Version 2.26.1)
 verwendet GTK+ Version 2.24.10 (gebaut gegen Version 2.24.10)
 verwendet Pango Version 1.30.0 (gebaut gegen Version 1.30.0)
 verwendet Fontconfig Version 2.9.0 (gebaut gegen Version 2.9.0)
 verwendet Cairo Version 1.10.2 (gebaut gegen Version 1.10.2)
Comment 6 Massimo 2013-04-24 11:29:54 UTC
One thing to notice here is that gegl-0.2.0 does not
contain the fix for Windows non-ASCII path names.

https://git.gnome.org/browse/gegl/tag/?id=GEGL_0_2_0
dates 2012-04-03 08:19:55 (GMT)

whereas the fix is from 2012-05-18
https://git.gnome.org/browse/gegl/log/gegl/buffer/gegl-tile-backend-file.c


OTOH, it seems that anyway there is another problem
because GIMP's output pasted in Description suggests that 
it is not (g_)open that fails, but dup, otherwise there
should be a warning "... Could not open ..."

https://git.gnome.org/browse/gegl/tree/gegl/buffer/gegl-tile-backend-file.c#n941

When GEGL_SWAP=RAM is set, before crashing does the output of 
gimp-2.8.exe --verbose contain any messages?
Comment 7 F Champigneul 2013-04-24 14:34:56 UTC
When GEGL_SWAP=RAM is set, before crashing, I still get exactly the same message as written above:
"
Loading module 'C:\Program Files\GIMP
2\lib\gimp\2.0\modules\libdisplay-filter-lcms.dll'
**
GEGL-gegl-tile-backend-file.c:ERROR:gegl-tile-backend-file.c:957:gegl_tile_backend_file_ensure_exist:
assertion failed: (self->i != -1)
"

Would there be a more recent version of GEGL for windows, even beta, which I could install and which would contain the 2012-05-18 fix for Windows non-ASCII path names, to see if it solves the issue?
Comment 8 Massimo 2013-04-24 16:42:37 UTC
(In reply to comment #7)
> When GEGL_SWAP=RAM is set, before crashing, I still get exactly the same
> message as written above:
> "
> Loading module 'C:\Program Files\GIMP
> 2\lib\gimp\2.0\modules\libdisplay-filter-lcms.dll'
> **
> GEGL-gegl-tile-backend-file.c:ERROR:gegl-tile-backend-file.c:957:gegl_tile_backend_file_ensure_exist:
> assertion failed: (self->i != -1)
> "

which means that the variable is not used, probably not set 
correctly. How do you set it?

> 
> Would there be a more recent version of GEGL for windows, even beta, which I
> could install and which would contain the 2012-05-18 fix for Windows non-ASCII
> path names, to see if it solves the issue?

You can try the 'Nightly Builds of The GIMP' at:

http://nightly.darkrefraction.com/gimp/

it says:

These binaries have been compiled and linked against 
the development versions of GEGL and BABL.
Comment 9 F Champigneul 2013-04-24 16:57:14 UTC
Yes, indeed the GEGL_SWAP was not correctly set
I had used the right command in a DOS window: SET GEGL_SWAP=RAM
and the variable was correctly set in that window (SET GEGL_SWAP would return GEGL_SWAP=RAM), but I realized that in the other DOS window from where I was starting GIMP, this variable was still not set.

Now I set GEGL_SWAP=RAM and start GIMP from the same DOS window, and ...I don't get the bug in that case! :)
Comment 10 Massimo 2013-04-24 17:59:27 UTC
So it was the same issue as in bug 676468 - closing as duplicate

Thanks for taking the time to report this bug.
This particular bug has already been reported into 
our bug tracking system, but we are happy to tell 
you that the problem has already been fixed. 
It should be solved in the next software version. 
You may want to check for a software upgrade.

*** This bug has been marked as a duplicate of bug 676468 ***
Comment 11 Eduard Braun 2013-04-24 18:16:11 UTC
Is it really a duplicate? It was already written in the description of this bug that it's the same problem but probably isn't fixed yet (therefore may have a different origin). This bug was only opened because it was proposed over at the old bug.

Bug 676468 comment 17 says "A fixed windows installer was just uploaded.". Tha would mean it should be fixed since version 2.8.2 (that was current at that time). Apparently it is not...

Please reopen this bug (or the old one) or make sure this is *really* fixed in trunk.
Comment 12 Massimo 2013-04-24 19:07:17 UTC
> Is it really a duplicate? It was already written in the description of this bug
> that it's the same problem but probably isn't fixed yet (therefore may have a
> different origin). This bug was only opened because it was proposed over at the
> old bug.
> 
> Bug 676468 comment 17 says "A fixed windows installer was just uploaded.". Tha
> would mean it should be fixed since version 2.8.2 (that was current at that
> time). Apparently it is not...
> 
> Please reopen this bug (or the old one) or make sure this is *really* fixed in
> trunk.

You're right it is a duplicate of 675591.

The reporter stated that his user profile contains non ASCII 
characters.

Feel free to reopen if you experience the same problem
with the binaries from the nightly build

*** This bug has been marked as a duplicate of bug 675591 ***
Comment 13 Eduard Braun 2013-04-24 19:17:10 UTC
Well, I don't have non ASCII characters in my profile name. I'm facing the crashes nonetheless.

Since I can't reopen bug 676468 I guess I need to file a new bug?
Comment 14 Massimo 2013-04-25 05:50:22 UTC
Reopened. 

So if you want to help, copy the full path name to 
GEGL's swap file. In my comment 4 at bug 675591

https://bugzilla.gnome.org/show_bug.cgi?id=675591#c4

it was: 

C:\Users\génèviève\AppData\Local\Microsoft\Windows\Temporary Internet
Files\gegl-0.2\swap\568-3

it should be something like that. Does it include any non ASCII
character?

and paste the output of gimp-2.8 --verbose
before crashing when run with the binaries from the nightly
build, I linked in comment 8.

Consider that gegl from master does not use 
gegl-tile-backend-file.c anymore, that is discussing how
it used to behave when gegl-0.2.0 was released is pointless
since it is no longer the code used today.
Comment 15 Massimo 2013-04-25 06:00:18 UTC
I now recalled that there is already a bug report open
for this issue under component GEGL. So marking as
duplicate of that one.

Feel free to add there every useful information you're 
able to collect.

Sorry for the noise.

*** This bug has been marked as a duplicate of bug 688361 ***
Comment 16 Eduard Braun 2013-04-25 18:02:21 UTC
OK, i see the problem now. In fact it *was* the bug with non ASCII characters but not easy to see , since actually I don't have any non ASCII characters in my profile name. But GIMP doesn't use the profile directory for GEGL swap anyway: It uses the "Temporary Internet Files" folder by Internet Explorer (why does it do that?).

And here's the crux: Since I'm working on a German localized Windows 7 the folder "Temporary Internet Files" is called "Temporäre Internetdateien". So there's the non ASCII character...