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 that code, XSane is not yet taking memory references, and options > are reloaded properly, so we mostly don't care about what's happening > at that stage. (but ...)
I set a memory watchpoint after the xsane Source menu had been built. The memory location for the watchpoint is the pointer that was stored in the label field of the gtk_menu structure. So the menu structure used in the final GUI is constructed with <menu>.label referencing a string in a buffer that is overwritten by all kinds of different data many times after that point. That can't be right, can it? > > Now the GUI is initialized and ready to go. I set a breakpoint on By the time we get to this point _three_ seperate gtk_menu structures have been created for the Source options. The first gtk_menu structure is the one used as the Source pop-up menu in the main xsane window. This structure contains the original .label reference mentioned which points to a memory location that has since been overwritten many, many times. (I don't know where the other two gtk_menu 'Source' menus are used in the GUI, if anywhere. Their .label fields point to different, but equally volatile, memory locations.) > What's interesting is what happens in and around xsane_panel_build(), > that effectively builds the options panels. > > Can you confirm that the issue happens only the first time you try to > set the option? There is memory churn at the menu.label reference every time any scanner option is selected until "something" happens and that particular block of memory becomes stable. I haven't been able to work out what particular combination of GUI manipulation fixes (or masks) the problem. It's not 100% reproducible. Sometimes it works after selecting something else once, sometimes it takes several attempts. I'm wondering if there is a race in the code somewhere that causes the net backend to allocate a new buffer under some circumstance, leaving the old original sitting idle... I'll try your other suggestions as soon as I get the chance. (RL is intruding at the moment. Hopefully this weekend.) -- Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
