On Fri, 25 Jul 2008, Julien BLACHE wrote:
Glad you narrowed it down. I've been on vacation the last couple of weeks
and had to put it on hold.
Bad:
- I think your patch may be the best option to fix this issue...
- ... but I'm afraid it may be leaking memory
[ . . . ]
Could you rework
Brad Sawatzky [EMAIL PROTECTED] wrote:
Hi,
Yeah, it will leak a few ten's of bytes every time that menu is
constructed... I couldn't see a simple workaround but I'll take another
look and see if I can rework the patch.
I've done it in the meantime. I was investigating another fix without
Brad Sawatzky [EMAIL PROTECTED] wrote:
Hi,
The patch fixes this problem by making a copy of the option name and
setting menu_items[].label to point to the new string (removing xsane's
dependence on a volatile memory structure).
Good and bad news.
Good:
- I can reproduce the issue here (a
Brad Sawatzky [EMAIL PROTECTED] wrote:
Hi,
What is the intent of duplicating s-opt into s-local_opt? If it is to
provide a stable local version of the scanner descriptors then shouldn't
Per the SANE standard, the descriptors have to remain available at the
same location until the device is
On Thu, 10 Jul 2008, Julien BLACHE wrote:
Brad Sawatzky [EMAIL PROTECTED] wrote:
What is the intent of duplicating s-opt into s-local_opt? If it is to
provide a stable local version of the scanner descriptors then shouldn't
Per the SANE standard, the descriptors have to remain
Brad Sawatzky [EMAIL PROTECTED] wrote:
Hi,
b) The pointer in the menu.label for the active source menu (in this case)
is not being kept current.
- FIX: Recreate/update the gtk menu and do a panel_rebuild every time
the net backend changes the NON-local opt array (since that is the
On Thu, 10 Jul 2008, Julien BLACHE wrote:
Brad Sawatzky [EMAIL PROTECTED] wrote:
b) The pointer in the menu.label for the active source menu (in this case)
is not being kept current.
- FIX: Recreate/update the gtk menu and do a panel_rebuild every time
the net backend
Brad Sawatzky [EMAIL PROTECTED] wrote:
Hi,
AFAICT, the fact that the Source menu for other backends work at all over
the netowrk is simply due to good fortune.
It is indeed highly probable that the epson backend is a special case
that exposes the bug.
Per the SANE standard, the descriptors
On Sun, 22 Jun 2008, Julien BLACHE wrote:
[ . . . ]
Anything in the option descriptor can change after the backend tells
the frontend to reload the options, and I think that's what you're
seeing with gdb when the net backend refreshes the option
descriptors. But the memory allocated by
On Wed, 25 Jun 2008, Julien BLACHE wrote:
Brad Sawatzky [EMAIL PROTECTED] wrote:
Up to that point, you're seeing the preferences loading code setting
options in a loop, resetting the options each time a reload is called
for by the backend, except for the options that caused a reload.
In
Brad Sawatzky [EMAIL PROTECTED] wrote:
Hi,
Up to that point, you're seeing the preferences loading code setting
options in a loop, resetting the options each time a reload is called
for by the backend, except for the options that caused a reload.
In that code, XSane is not yet taking memory
Brad Sawatzky [EMAIL PROTECTED] wrote:
Hi,
From what I found, I think it really is a bug in xsane. (xsane assumes a
memory structure is static but this is not guaranteed when the network
backend is used.)
Thanks for spending time on this one!
However I am a bit doubtful as to the origin of
reassign 487475 libsane
retitle 487475 libsane: net backend option descriptors handling incorrect,
breaking SANE standard
tags 487475 - patch
merge 487475 307088
thanks
Brad Sawatzky [EMAIL PROTECTED] wrote:
The problem occurs in xsane when accessing an epson/epkowa driver through
the network
On Sun, 22 Jun 2008, Julien BLACHE wrote:
However I am a bit doubtful as to the origin of the bug. I'd expect
the problem would manifest itself with other backends too.
Yeah, I had though so too...
AFAICT the opt pointer that xsane used was directed into a generic buffer
that sanei_* used for
Brad Sawatzky [EMAIL PROTECTED] wrote:
Hi,
I'll admit to getting a little lost in the sanei_* calls that do the dirty
work though...
That actually indicates you still have some sanity left :-)
Anyway, yes, the string list in the option descriptors are not stable
and can change over time,
Brad Sawatzky [EMAIL PROTECTED] wrote:
everything would just work. However, if you use gdb to break on writes to
the memory location stored during the initial menu_items[i].label =
str_list[i]; line (in the unpatched xsane-front-gtk.c:xsane_option_menu_new()
function) you should find that it
Brad Sawatzky [EMAIL PROTECTED] wrote:
everything would just work. However, if you use gdb to break on writes to
the memory location stored during the initial menu_items[i].label =
str_list[i]; line (in the unpatched xsane-front-gtk.c:xsane_option_menu_new()
function) you should find that it
OK, here's a summarized gdb session. Sorry about the length, I hope it's
useful...
I set a breakpoint on xsane_option_menu_new() and wait for my menu-item of
interest (the source menu which should eventually contain Flatbed and
Transparency Unit) to trigger. When the Flatbed menu item is
Package: xsane
Version: 0.995-3
Severity: normal
Tags: patch
The problem occurs in xsane when accessing an epson/epkowa driver through
the network backend. Trying to change options like binary/gray/color,
resolutions, etc., in xsane results in a dialog box with 'Failed to set
value of option
19 matches
Mail list logo
