Crash disabling plugins and (related) bug report about handling of image files

[Daniel Leidert]

Hi,

During examining [1] I found a reproducible crash:

I've created a test SVG file (empty one is good enough) test.svg, start
bluefish. Now double-clicking this file in the bluefish filebrowser
inserts an <img> tag - I _guess_, this is done by the zencoding plugin -
and this is what [1] is about. Can you confirm, this is caused by the
zencoding plugin?

Now with the next step opening the preferences dialog -> plugins: As
soon as I disable the zencoding plugin and hit "Apply", bluefish
crashes. The backtrace is attached. This one needs a fix.

Regards, Daniel

[Daniel Leidert]

Am Dienstag, den 11.02.2014, 12:02 +0100 schrieb Daniel Leidert:

[..]

Post by Daniel Leidert
Now with the next step opening the preferences dialog -> plugins: As
soon as I disable the zencoding plugin and hit "Apply", bluefish
crashes. The backtrace is attached. This one needs a fix.

Hm. Reversing these actions (first disable plugin, then double-click the
file) and closing bluefish without saving the file makes bluefish crash
directly at startup. I wonder if this is the cause of [2]

[1] https://bugs.launchpad.net/ubuntu/+source/bluefish/+bug/1248595
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731821

Regards, Daniel

[Olivier Sessink]

Post by Daniel Leidert
[1] https://bugs.launchpad.net/ubuntu/+source/bluefish/+bug/1248595

fixed in svn!

Olivier

[Olivier Sessink]

Post by Daniel Leidert
Hi,
I've created a test SVG file (empty one is good enough) test.svg, start
bluefish. Now double-clicking this file in the bluefish filebrowser
inserts an <img> tag - I _guess_, this is done by the zencoding plugin -
and this is what [1] is about. Can you confirm, this is caused by the
zencoding plugin?

I don't think it is related to the plugin. this is hardcoded in
filebrowser2.c. However, the crash report showed a real problem if an
invalid URL is passed to the filebrowser.

disabling a plugin only sets a 0 in a list instead of a 1, only after
restart this has any effect. So I guess this was caused by earlier
memory corruption.

try to debug with valgrind `grep valgrind src/*.c` to get the best
options to run valgrind. That will give better information where the
memory coruption is started.

Olivier

[Daniel Leidert]

Post by Olivier Sessink

Hi,

[..]

Post by Olivier Sessink
disabling a plugin only sets a 0 in a list instead of a 1, only after
restart this has any effect. So I guess this was caused by earlier
memory corruption.
try to debug with valgrind `grep valgrind src/*.c` to get the best
options to run valgrind. That will give better information where the
memory coruption is started.

Ok. Another thing I missed earlier: I created test.svn inside /tmp. From
a running bf instance I changed from $(HOME) to / to /tmp in the bf
filebrowser. This somehow leads to the following entry in the bf

Post by Olivier Sessink
recent_dirs: file://

and this seems to have caused the issue. After your last change to

Post by Olivier Sessink
** (bluefish:4808): WARNING **: cannot handle uri file://
cleanup_scanner, memory scancache 0(0Kb+0Kb) found 0(0Kb) fcontext 0(0Kb) = 0Kb
** (bluefish:4808): WARNING **: failed to list directory in filebrowser: Vorgang wird nicht unterstützt (15)

IMHO entries like the following shouldn't be found in session-2.0,
because these are not valid URIs:

recent_dirs: file:/
recent_dirs: file://

These are not valid URIs. How do they appear?

Regards, Daniel

[Andrius]

When I select root in fb, in sesion-2.0 file the entry looks like

recent_dirs:file:///
However, when I reopen bf with this entry as default dir, the fb dir_menu shows "file://" which is not valid directory. When root selected it should show just "/"

Andrius

________________________________
Sent: Thursday, February 13, 2014 10:34 PM
Subject: Re: Crash disabling plugins and (related) bug report about handling of image files

Post by Olivier Sessink

Hi,

[..]

Post by Olivier Sessink
disabling a plugin only sets a 0 in a list instead of a 1, only after
restart this has any effect. So I guess this was caused by earlier
memory corruption.
try to debug with valgrind `grep valgrind src/*.c` to get the best
options to run valgrind. That will give better information where the
memory coruption is started.

Ok. Another thing I missed earlier: I created test.svn inside /tmp. From
a running bf instance I changed from $(HOME) to / to /tmp in the bf
filebrowser. This somehow leads to the following entry in the bf

Post by Olivier Sessink
recent_dirs: file://

and this seems to have caused the issue. After your last change to

Post by Olivier Sessink
** (bluefish:4808): WARNING **: cannot handle uri file://
cleanup_scanner, memory scancache 0(0Kb+0Kb) found 0(0Kb) fcontext 0(0Kb) = 0Kb
** (bluefish:4808): WARNING **: failed to list directory in filebrowser: Vorgang wird nicht unterstützt (15)

IMHO entries like the following shouldn't be found in session-2.0,
recent_dirs: file:/
recent_dirs: file://
These are not valid URIs. How do they appear?
Regards, Daniel
--
To unsubscribe from this list: send the line "unsubscribe bluefish-dev" in
Bluefish web site: http://bluefish.openoffice.nl/

[Olivier Sessink]

Post by Daniel Leidert

Post by Olivier Sessink

Hi,

[..]

Post by Olivier Sessink
disabling a plugin only sets a 0 in a list instead of a 1, only after
restart this has any effect. So I guess this was caused by earlier
memory corruption.
try to debug with valgrind `grep valgrind src/*.c` to get the best
options to run valgrind. That will give better information where the
memory coruption is started.

Ok. Another thing I missed earlier: I created test.svn inside /tmp. From
a running bf instance I changed from $(HOME) to / to /tmp in the bf
filebrowser. This somehow leads to the following entry in the bf

Post by Olivier Sessink
recent_dirs: file://

and this seems to have caused the issue. After your last change to

fixed in svn!

Olivier