Re: [Geeqie-devel] NULL-ptr crash in image_read_ahead_done_cb()
On Fri, 29 Jan 2016 23:00:17 +0800, Flos Lonicerae wrote: > But for old version of geeqie - for example the one provided by nux repo: > > geeqie-1.1-10.el6.nux.x86_64 > > did not have this issue. That repo doesn't do anything different. The package you refer to has been copied from Fedora 19 verbatim. See package %changelog. As why this repo is stuck at release -10 whereas the corresponding Fedora package has seen more fixes, that's really strange. It is also bad style to build a src.rpm for a completely different target and not mention anything of that in the package changelog. It explains why sometimes people contact me by email and ask about packages and repos I haven't heard before. My name is found in the packages, although I have nothing to do with the packages. It would be much more friendly to add a brief message to the %changelog telling that a src.rpm has been adapted for a different repo. Anyway, upstream Geeqie is at 1.2.x, and Fedora has upgraded to those releases, too. It is not trivial to test a new version for regressions. And if a new version introduces too many changes, it is not easy either to check whether patches are still necessary. So, sometimes packagers rebase their packages to a pristine upstream release, dropping patches and re-evaluating at runtime over a longer period whether patches are still needed. [Bcc to the repo maintainer] -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140 ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] gQview feature lost : properties
On Tue, 11 Aug 2015 23:36:00 +0100, Klaus Ethgen wrote: Am Di den 19. Mai 2015 um 15:51 schrieb me...@gmx.fr: In the old gQview there was a properties feature in the right click on an image. I miss it in geeqie, when I have to check the size of a file after resizing it, for example. Here is a picture to show what I mean: http://citrotux.org/gqview-image-properties.png Would it be possible to add the properties context menu from gqview to geeqie ? I'll have a look. The image overlays have replaced that. Key 'I' and menu View Image Overlay ... -- ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Version 1.2.1
On Wed, 12 Aug 2015 14:24:16 -0400, Frank Peters wrote: Klaus Ethgen wrote: I released version 1.2.1 as a bugfix release. Where can I get the source for this release? I checked sourceforge and it has 1.1 as the latest. 1.2 has not been released as tarball either. You can check out the code from the geeqie.org git server. For example: $ git clone git://www.geeqie.org/geeqie.git $ cd geeqie $ git checkout v1.2.1 $ autoreconf -f -i ; intltoolize $ ./configure … -- ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Bad optimization in renderer-tiles.c
On Tue, 11 Aug 2015 23:07:06 +0200, Uwe Ohse wrote:
Hello,
in src/renderer-tiles.c there is a really bad optimization, starting at about
line 1336 (current qeeqie.org git):
1336 else if ((pr-zoom == 1.0 || pr-scale == 1.0)
1337 pr-aspect_ratio == 1.0
1338 !has_alpha
1339 orientation == EXIF_ORIENTATION_TOP_LEFT
1340 !(pr-func_post_process !(pr-post_process_slow
fast))
1341 !(rt-stereo_mode PR_STEREO_ANAGLYPH))
1342 {
1343 /* special case: faster, simple, scale 1.0, base
orientation, no postprocessing */
1344 cairo_t *cr;
1345 cr = cairo_create(it-surface);
1346 cairo_rectangle (cr, x, y, w, h);
1347 gdk_cairo_set_source_pixbuf(cr, pr-pixbuf, -it-x -
GET_RIGHT_PIXBUF_OFFSET(rt), -it-y);
1348 cairo_fill (cr);
1349 cairo_destroy (cr);
1350 }
it looks good, but is dead slow, for each and every call to
gdk_cairo_set_source_pixbuf takes at least 15 milliseconds on my not
really slow machine, which amounts to over 2 seconds if 144 tiles have to be
drawn (tested with many jpegs and a few large pngs).
i propose to remove this optimization until someone fixes it. After removal
geeqie is fast, again.
http://sourceforge.net/p/geeqie/bugs/213/
( Created: 2014-12-05 )
--
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel
[Geeqie-devel] NULL-ptr crash in image_read_ahead_done_cb()
It's not easy to reproduce, but if one is mad and follows the steps and presses
the keys a few dozens times, there's a slight chance one can trigger it. Not
much to investigate it further.
Forwarding from Sami Farin 2015-08-07 16:40:44 EDT:
| to reproduce: quickly keep pressing f (fullscreen) and page down
| (next file) keys.
|
| attached patch is a kind of workaround, I did not inspect further
| is this threading issue etc
Full backtrace: https://bugzilla.redhat.com/attachment.cgi?id=1027647
Patch:
https://bugzilla.redhat.com/attachment.cgi?id=1060482action=diffcontext=patchcollapsed=headers=1format=raw
--- geeqie/src/image.c.bak 2014-11-30 13:07:06.0 +0200
+++ geeqie/src/image.c.bak 2015-08-07 23:18:55.019350782 +0300
@@ -475,6 +475,8 @@ static void image_read_ahead_done_cb(Ima
{
ImageWindow *imd = data;
+ if (!imd-read_ahead_fd || !imd-read_ahead_il) return;
+
DEBUG_1(%s read ahead done for :%s, get_exec_time(),
imd-read_ahead_fd-path);
if (!imd-read_ahead_fd-pixbuf)
--
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel
[Geeqie-devel] TIFF loading stability?
Hello everyone! Recently I've received two crash reports for Geeqie 1.1 (patched a bit) from somebody who had browsed through a collection of large TIFF files (25 MB). The crash is not reproducible, but might be related to skipping to the next file while loading the current file is not done. The symptoms are similar. While gdk-pixbuf mentions width = 7898 height = 3318 Geeqie's own code in pr_zoom_clamp at pixbuf-renderer.c:1755 refers to w = 0 h = 0 but the reason for the crash is it somehow uses an invalid pixbuf renderer, when trying to call pr-renderer-invalidate_all(pr-renderer), and segfaults. https://bugzilla.redhat.com/attachment.cgi?id=960178 The call of pr_zoom_clamp() leads back to pixbuf_renderer_set_size_early(), unless I misread the code. The second time the user has encountered a crash, it ran into a NULL pixbuf renderer pointer early in pixbuf_renderer_set_size_early(), #0 pixbuf_renderer_set_size_early (pr=0x0, width=3465, height=5202) at pixbuf-renderer.c:2916 zoom = 1 2915 zoom = pixbuf_renderer_zoom_get(pr); 2916 pr-image_width = width; 2917 pr-image_height = height; and interestingly, pixbuf_renderer_zoom_get(pr) tries to protect against an invalid pr ptr, g_return_val_if_fail(IS_PIXBUF_RENDERER(pr), 1.0); but that doesn't help outside that function, of course. https://bugzilla.redhat.com/attachment.cgi?id=962883 It looks like some sort of race to me. Any ideas, anyone? -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Another UI trouble, or is it just me?
On Tue, 12 Aug 2014 18:27:55 + (UTC), Ian Zimmerman wrote: My situation was I had a directory with both tifs and jpgs, and I wanted to see only the jpgs. So I wanted to temporarily disable the tif entry. I tried unchecking the checkbox by the tif line (without knowing what you tell me above), but that didn't seem to do anything, even after clicking Apply. Which may be a bug or by design ... that the file list isn't refreshed and reduced to just the filtered files prior to leaving the directory. On the contrary, if one starts with Disable file filtering and then turns on file filtering, the list of files is reduced to the enabled types immediately. -- ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Another UI trouble, or is it just me?
On Tue, 12 Aug 2014 03:39:34 + (UTC), Ian Zimmerman wrote: I am in the Preferences/Files dialog tab and I cannot figure out how to disable just one file type. The dialog has a checkbox next to each type and at the bottom Add and Remove buttons. Does the Remove button apply to all checked rows or to rows picked with the normal selection mechanism? The Remove button applies to the currently _highlighted_ row. The Add button appends a new row at the bottom. If it is the selection, what are the checkboxes for? You can have multiple rows per file type, so the checkbox enables/disables a line. If it is the checkboxes, do I really have to uncheck each one by one before I can disable this one type? I don't understand that question. If there's just one type, I fail to see why you would want to uncheck each one by one because that would refer to multiple rows. If you want to disable all filters, use the checkbox at the very top. -- ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
[Geeqie-devel] Crashes with LCMS2 patch
Hello everyone! The patch for LCMS2 support that has been published on this list does the following to generate the tooltip texts for Image profile and Screen profile: cmsUInt8Number profileID[17]; profileID[16] = '\0'; cmsGetHeaderProfileID(profile, profileID); return g_strdup(profileID); This results in unprintable strings that can crash g_markup, because these profile IDs are based on MD5. Even with LCMS1 unpatched, Geeqie could not print such a Screen profile name and warned about it in terminal output (probably causing a crash in special cases, too). One safer way to retrieve printable image/screen profile names is this: cmsUInt32Number r; char buffer[20]; buffer[0] = '\0'; r = cmsGetProfileInfoASCII(profile, cmsInfoDescription, en, US, buffer, 20); return g_strdup(buffer); Find the full revised patch at: http://mschwendt.fedorapeople.org/geeqie-1.1-lcms2.patch -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] [PATCH] Fix SEGV crasher (fullscreen + read-ahead)
On Sat, 8 Feb 2014 13:23:51 -0500, David Favro wrote: I've been holding off for some time on sending in this patch but since there's talk of a release I thought I'd go ahead now. Hmmm, some of my tickets (patches and/or bug reports) have not been responded to yet, such as http://sourceforge.net/p/geeqie/patches/28/ It would be great, if a new release included such fixes. Is the SF.net ticket system still used? -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Geeqie-1.1 LCMS2 Patch
On Fri, 13 Dec 2013 06:43:25 +0200, Niko Sauer wrote: Let me try to explain. In the code snippet above, the two conditionals build a logical AND, so that in order to build with LCMS2, both HAVE_LCMS and HAVE_LCMS2 must be defined. If HAVE_LCMS were undefined, the HAVE_LCMS2 condition would not be reached. Then lcms2.h could not be included, and the source code would not compile. exif-common.c: In function ‘exif_build_formatted_ColorProfile’: exif-common.c:417:2: error: unknown type name ‘cmsUInt8Number’ cmsUInt8Number profileID[17]; ^ exif-common.c:417:17: warning: unused variable ‘profileID’ [-Wunused-variable] cmsUInt8Number profileID[17]; ^ make[1]: *** [exif-common.o] Error 1 This is quite strange. Why is it strange? ;) Can we agree that it's a logical AND? Can we also agree that HAVE_LCMS must be defined or else the HAVE_LCMS2 conditional block won't ever be reached? There are also code sections that are conditional on just HAVE_LCMS, so they would never be built if only HAVE_LCMS2 is defined. If you build Geeqie with that patch, after you run configure, what values do you get for HAVE_LCMS and HAVE_LCMS2? Here, HAVE_LCMS is undefined, because configure finds LCMS2 and takes that one. The adjusted patch is this: http://pkgs.fedoraproject.org/cgit/geeqie.git/plain/geeqie-1.1-lcms2.patch Are we talking about the same patch? Of course. The one I refer to is https://gitorious.org/geeqie/emikulic-geeqie/commit/1548a68d26046b6aa467e56ca2c8f5444b95a23b.patch If I don't erase that (infernal) line, the compiler looks at lcms.h instead of lcms2.h. Why would it do that? If you erase that line, precisely the opposite happens. The type cmsUInt8 is defined in lcms2.h. lcms2.h won't even be included in exif-common.c, if HAVE_LCMS is undefined. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Geeqie-1.1 LCMS2 Patch
On Thu, 12 Dec 2013 06:34:54 +0200, Niko Sauer wrote: Which line have you deleted? There's a bug in the patch, because HAVE_LCMS is undefined, and that leads to some files (such as exif_common.c) not including lcms2.h and breaking compilation. It is line 296 which reads as follows: 296AC_DEFINE(HAVE_LCMS, 1, [define to enable use of color profiles with lcms]) Yes, that line must be present, or else Geeqie does not compile. Why? See e.g. beginning of src/exif_common.c, where both HAVE_LCMS and HAVE_LCMS2 must be defined for LCMS2 headers to be included. #ifdef HAVE_LCMS /*** color support enabled ***/ #ifdef HAVE_LCMS2 #include lcms2.h #else #include lcms.h #endif #endif […] I'm not sure that I understand your comment. Let me try to explain. In the code snippet above, the two conditionals build a logical AND, so that in order to build with LCMS2, both HAVE_LCMS and HAVE_LCMS2 must be defined. If HAVE_LCMS were undefined, the HAVE_LCMS2 condition would not be reached. Then lcms2.h could not be included, and the source code would not compile. exif-common.c: In function ‘exif_build_formatted_ColorProfile’: exif-common.c:417:2: error: unknown type name ‘cmsUInt8Number’ cmsUInt8Number profileID[17]; ^ exif-common.c:417:17: warning: unused variable ‘profileID’ [-Wunused-variable] cmsUInt8Number profileID[17]; ^ make[1]: *** [exif-common.o] Error 1 -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Geeqie-1.1 LCMS2 Patch
On Wed, 11 Dec 2013 06:47:40 +0200, Niko Sauer wrote: On 12/09/13 19:43, Michael Schwendt wrote: On Fri, 06 Dec 2013 03:20:53 +, Omari Stephens wrote: Niko: do you know if render speed is affected? It appears to be visibly faster here. ISTR that render speed was one downside to LCMS2, but that may have changed since I last heard that, and also it might not be significant (I haven't used a project using LCMS2 before). On 12/05/2013 04:47 AM, Niko Sauer wrote: I found a patch that will enable lcms2 when compiling Geeqie-1.1.This is Gitorious Commit 1548a68. There is a small bug in the patch that I remedied by deleting one single line. The new patch is attached. Which line have you deleted? There's a bug in the patch, because HAVE_LCMS is undefined, and that leads to some files (such as exif_common.c) not including lcms2.h and breaking compilation. It is line 296 which reads as follows: 296 AC_DEFINE(HAVE_LCMS, 1, [define to enable use of color profiles with lcms]) Yes, that line must be present, or else Geeqie does not compile. Why? See e.g. beginning of src/exif_common.c, where both HAVE_LCMS and HAVE_LCMS2 must be defined for LCMS2 headers to be included. #ifdef HAVE_LCMS /*** color support enabled ***/ #ifdef HAVE_LCMS2 #include lcms2.h #else #include lcms.h #endif #endif […] -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Geeqie failed to open a g3 tiff fax file segmentation fault?
On Thu, 13 Dec 2012 15:31:03 +0800, Kite Lau wrote: Hi, as the subject. is g3 tiff format supported? When I try to open a g3 tiff fax file, geeqie crashed. It uses the gdk_pixbuf2 library to open most image file formats. I've never had any problems opening Fax G3 TIFF files with Geeqie. Can you get a detailed backtrace so one can see where/how it crashes? [With sufficiently modern Linux distributions, there are system services that intercept crashes and create backtraces semi-automatically.] -- Fedora release 18 (Spherical Cow) - Linux 3.6.10-4.fc18.x86_64 loadavg: 0.22 0.33 0.15 -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Geeqie failed to open a g3 tiff fax file segmentation fault?
On Thu, 13 Dec 2012 16:39:11 +0800, Kite Lau wrote: I do not have much knowledge to to backtracing now, but here is the error I could see from the terminal (attached pls find the fax file in case you need it): bash-4.2$ geeqie fax00047.tiff libtiff-geeqie: 1: Strip out of range, max 1. Segmentation faults. Thanks. That's specific to new code in Geeqie 1.1 and crashes in libtiff. Geeqie 1.0 is not affected. Backtrace following shortly... got to wait for downloading fresh -debuginfo packages. -- Fedora release 18 (Spherical Cow) - Linux 3.6.10-4.fc18.x86_64 loadavg: 0.16 0.53 0.43 -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Fedora 17 breaks drag-drop operations
On Fri, 23 Nov 2012 16:52:48 -0800 (PST), davewh wrote: davewh wrote: yum upgrade fixed it! I don't know what version of what broke it, but after the F17 install I had done updates and noticed the menu not working later. Some time after the recent updates, I noticed it was working again. Still the 1.0 version of Geeqie, so must have been some library. Glad it's back! Well, it's back. Another yum upgrade broke it. I have two systems that I did the update on and they both lost the functionality. I have a third system that still works, but it will be getting updated soon, and I expect it to be broken soon, too, and it'll be back to having a Konqueror or Dolphin file manager open to use as a drop surface. Can anyone comment on what library (if any) that Geeqie uses to respond to a drop operation in the directory tree? There aren't too many updates for F17. You could track down the culprit via /var/log/yum.log or rpm -qa --last|head -50 or something. There's also yum downgrade … to verify whether a particular package is the one that breaks. Here, with F17 x86_64 and GNOME Shell, drag'n'drop from Nautilus to Geeqie has never failed. The specifics for a test-case are not known, however. -- Fedora release 17 (Beefy Miracle) - Linux 3.6.7-4.fc17.x86_64 loadavg: 0.95 0.82 0.42 -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Problem with full screen in 1.1 on Xubuntu 12.10
On Thu, 22 Nov 2012 07:20:58 +0200, George Pop wrote: Hi, I have just compiled Geeqie 1.1 from source on Xubuntu 12.10 and I have a problem. In full screen, the window manager's task bar (panel) remains visible. The behavior is the same even after experimenting with the Location and Stay above other windows settings in Preferences / Windows / Full screen. I also have Geeqie 1.0 installed from the official Ubuntu repository and full screen works properly in that version. Please verify whether this is a Geeqie bug. That is because the Geeqie 1.0 package in Ubuntu applies a patch. The corresponding ticket is this: http://sourceforge.net/tracker/index.php?func=detailaid=2925034group_id=222125atid=1054680 -- Fedora release 17 (Beefy Miracle) - Linux 3.6.6-1.fc17.x86_64 loadavg: 0.03 0.05 0.10 -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
[Geeqie-devel] Geeqie 1.1 keyword text editor regression?
Could it be that the new keyword cache in Geeqie 1.1 disturbes the keyword text box? 1. display image 2. Ctrl+K 3. focus Keywords sidebar 4. type some text Actual results: After typing a first character, the cursor jumps into the second line. Expect results: It would be possible to type full keywords (without adding them to the keyword tree at the right side). I've had a brief look at bar_keywords.c and the diff against 1.0, but it seems it's a side-effect of the changes in metadata.c -- Fedora release 17 (Beefy Miracle) - Linux 3.5.2-1.fc17.x86_64 loadavg: 0.03 0.04 0.11 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Geeqie 1.1
On Tue, 07 Aug 2012 17:05:58 +0200, Vladimir Nadvornik wrote: removing unknown sidecar /home/misc/tmp/stresstest/000454.JPG: �Jd 8 fd magick mismatch at filedata.c:629 ** ERROR:filedata.c:448:file_data_ref_debug: assertion failed: (fd-magick == 0x12345678) Aborted Hmm, this could be corrupted anywhere. My brute-force change from last year is this: http://pkgs.fedoraproject.org/cgit/geeqie.git/plain/geeqie-1.0-vflist-refresh.patch With it and a couple of tiny patches (some cherry-picked post-1.0 ones), users have not reported any further crashes: http://pkgs.fedoraproject.org/cgit/geeqie.git/tree/ Anyway, I'll try to create an isolated stresstest script. -- Fedora release 17 (Beefy Miracle) - Linux 3.5.0-2.fc17.x86_64 loadavg: 0.19 0.31 0.22 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Geeqie 1.1
On Mon, 06 Aug 2012 16:51:43 +0200, Vladimir Nadvornik wrote:
The tarball I used for creating the testing packages can be downloaded here:
http://download.opensuse.org/repositories/home:/nadvornik:/geeqie:/testing/Debian_5.0/geeqie_1.1.orig.tar.gz
That one still crashes when letting an external tool/program run wild in
the current working directory (such as renaming/moving files or altering
the case of file extensions). Backtrace below.
filedata.c:446: fd magick mismatch at filedata.c:2656
**
ERROR:filedata.c:448:file_data_ref_debug: assertion failed: (fd-magick ==
0x12345678)
I can't tell what is the culprit, just that the Fedora package uses a
stripped-down vflist_refresh function which makes Geeqie not crash.
Thread 1 (Thread 0x77fd5980 (LWP 7866)):
#0 0x003ffa835925 in raise () from /lib64/libc.so.6
#1 0x003ffa8370d8 in abort () from /lib64/libc.so.6
#2 0x003ffc468827 in g_assertion_message () from /lib64/libglib-2.0.so.0
#3 0x003ffc468d44 in g_assertion_message_expr ()
from /lib64/libglib-2.0.so.0
#4 0x004508a2 in file_data_ref_debug (file=file@entry=
0x4dbdbb filedata.c, line=line@entry=2656, fd=fd@entry=0xd6fc90)
at filedata.c:448
#5 0x00453368 in file_data_send_notification (fd=0xd6fc90, type=
NOTIFY_REREAD) at filedata.c:2656
#6 0x004538b1 in file_data_check_sidecars (basename_list=
0xd2fa00 = {...}) at filedata.c:630
#7 0x003ffc438320 in g_hash_table_foreach () from /lib64/libglib-2.0.so.0
#8 0x004541ee in filelist_read_real (dir_path=optimized out,
files=files@entry=0x95baf8, dirs=dirs@entry=0x0,
follow_symlinks=follow_symlinks@entry=1) at filedata.c:1006
#9 0x004545fe in filelist_read (dir_fd=optimized out,
files=files@entry=0x95baf8, dirs=dirs@entry=0x0) at filedata.c:1017
#10 0x004bb5f2 in vflist_refresh (vf=vf@entry=0x95ba90)
at view_file_list.c:1782
#11 0x004b77db in vf_refresh (vf=vf@entry=0x95ba90) at view_file.c:648
#12 0x004b7809 in vf_refresh_idle_cb (data=0x95ba90)
at view_file.c:1006
#13 0x003ffc447695 in g_main_context_dispatch ()
from /lib64/libglib-2.0.so.0
#14 0x003ffc4479c8 in ?? () from /lib64/libglib-2.0.so.0
#15 0x003ffc447dc2 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#16 0x00300a54ac57 in gtk_main () from /lib64/libgtk-x11-2.0.so.0
#17 0x0041867c in main (argc=1, argv=0x7fffe5d8) at main.c:921
A debugging session is active.
Inferior 1 [process 7866] will be killed.
--
Fedora release 17 (Beefy Miracle) - Linux 3.5.0-2.fc17.x86_64
loadavg: 0.43 0.54 0.31
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Fedora 17 breaks drag-drop operations
On Sun, 15 Jul 2012 18:26:19 +, Dave Withheld wrote: I'm (was) using Geeqie like a file manager; drag selected files from the file list and drop them on folders in the tree view and wait for the menu to pop up and choose move, copy or link. Works for me. Fedora 17 x86_64 with default GNOME Shell. I'm using KDE, which is what I used on FC13 and FC14. I might give KDE a try, too, but likely no sooner than end of next week. I don't know if the problem with Geeqie not popping up the menu is related to the nvidia driver. It's ATI Radeon graphics here with xorg drivers as included with Fedora. -- Fedora release 17 (Beefy Miracle) - Linux 3.4.4-5.fc17.x86_64 loadavg: 0.99 0.99 0.89 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Fedora 17 breaks drag-drop operations
On Sat, 14 Jul 2012 12:15:05 +0200, Michael Schwendt wrote: On Sat, 14 Jul 2012 01:04:52 -0700 (PDT), davewh wrote: I have come to depend on Geeqie for image organization and viewing. I empty my camera's card by dragging images to appropriate directories, symbolic links in the wallpapers directory for the really good ones. I've been hapily organizing images on Fedora 13 and 14 for some time, but recently I upgraded to Fedora 17 and no more drag-and-drop. If I hold down the Ctrl or Shift, the operation works, but with no modifier, nothing happens; no menu pops up, no move, copy or symlink. Anyone else seen this? Any known fix? I can open a file manager (KDE's Konqueror or Dolphin) and drag to there and the KDE menu pops up, but no joy when dropping in Geeqie's tree view. I tried downloading the source and compiling myself, no change. I didn't do anything special in the build, just the defaults. Is there something I could do differently? Where exactly do you move the files? To a destination folder? If I move an image or a folder to a folder in Geeqie's folder list, the small pop-up dialog appears. If I hold down Ctrl or Shift, the pop-up dialog is skipped. That's with default GNOME Shell and its file manager (Nautilus). It's the same within a Openbox session and Nautilus. I don't know/remember whether it has worked differently ever before. Same behaviour with RHEL 6 (GNOME 2.x) and Fedora 15 (GNOME Shell). -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] geeqie: 1.0-8 repeatable core dumps
On Mon, 27 Jun 2011 05:36:31 -0400 (EDT), JP (Justin) wrote: Hi, When performing the following: 1. Viewing images in a directory with 100 pictures. 2. Selecting images, copying their paths. 3. Moving the images from the command line to a different directory. 4. Scrolling up back to the top with the mouse wheel (for the thumbnails). 5. Results in a coredump everytime. -- Crash: user@host:/home/user/pictures$ gqview . This is a compatibility alias for Geeqie! Please use /usr/bin/geeqie instead! Could not init LIRC support Address already in use: /home/user/.config/geeqie/.command ** ERROR:../../src/exif-common.c:641:exif_free_fd: assertion failed: (fd-exif == exif) Aborted (core dumped) Find a patch here (problem description is available there and in the linked Fedora ticket): http://sourceforge.net/tracker/?func=detailaid=3189129group_id=222125atid=1054680 The patch is also filed as: http://sourceforge.net/tracker/?func=detailaid=3201371group_id=222125atid=1054682 -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] new logo
On Tue, 10 May 2011 08:53:57 +0200, MB wrote: It looks more like Gooqie than Geeqie. Perhaps even Gööqie. I'd favour a logo that didn't contain the letters of the name Geeqie at all. A small picture with informative value and (if possible) recognition value Thanks for the valuable feedback, Michael. General question: What sizes (in px.)should a logo / icon nawadays have for the various uses? (ranging from a desktop icon to the tiny icon in window headers). Is there a sort of manual or convention you can point me to? http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#install_icons so, 48x48 (and optionally an SVG) is recommended there. Typical sizes have been Large 48x48, Medium 32x32 (Windows 9x), Small 22x22 (GNOME Small 24x24), Extra Small 16x16. One can find also Extra Large 256x256 (e.g. the max size of icons in Windows 7/Vista) and 512x512 for some Apple platforms. This is on a rather default Fedora 15 GNOME 3 install: $ find /usr/share/icons/hicolor/256x256/apps|wc -l 24 $ find /usr/share/icons/hicolor/48x48/apps|wc -l 105 $ find /usr/share/icons/hicolor/16x16/apps|wc -l 115 $ find /usr/share/icons/hicolor/22x22/apps|wc -l 172 $ find /usr/share/icons/hicolor/24x24/apps|wc -l 68 -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] new logo
On Mon, 09 May 2011 12:13:07 +0200, MB wrote: hello, I had the idea of creating a new Geeqie logo. Attached is the first idea, that could be further developed... or abandoned. The first two ees were meant to indicate that it's a viewer, and even that it is capable of displaying stereoscopic images. The eye-styled e itself could be an icon. any opinions and suggestions welcomed! It looks more like Gooqie than Geeqie. Perhaps even Gööqie. I'd favour a logo that didn't contain the letters of the name Geeqie at all. A small picture with informative value and (if possible) recognition value. If displayed in a list of app icons, user would immediately assume that it's an image viewer. Which is why a picture with a magnifying-glass is a good choice for an image viewer app icon (like Eye of GNOME). The idea with two eyes (or eye-balls) goes into the right direction. The geeqie_logo_02_icon.png doesn't resemble a single eye or 'e', however. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] On refcounting
On Sat, 7 May 2011 11:41:00 +0200, VN wrote:
FWIW, and considering that the current refcounting in Geeqie is
troublesome, you've got my blessing. :-) I'm all for a central list of
the current directory's file data objects, with added maintenance
structures on top of that.
What do you mean by _central_? There is ViewFile-list for each window,
but then there are standalone files too.
Central = a global list for each view. With a manager that maintains the
list (including the refreshing of the directory contents if external tools
modify the dir), the parent/child relationships, the references to
additional data caches, and the freeing of the FileData objects. The
manager would have the ultimate decision power whether and when to free
memory and to remove something from the list.
Additionally, the FileData unref method is questionable already (not just
due to its fd-magick checking and special handling of child nodes), since
for example it does
fd-ref--;
if (fd-ref == 0)
{
/* decide whether to file_data_free() or return earlier */
}
return;
and hence doesn't cover the case that ref0, and the responsibility to
drop ptrs to freed FileData from any lists or locals, is not within this
method.
file_data_free is called when the file and it's parent and children all have
zero ref count. Then it frees whole group.
Who ensures that it is called like that?
The current implementation bails out if these contraints aren't met,
but the refcount is decreased nevertheless, as that's the first thing the
unref method does. The unref method so far results in several of its
assertions to abort Geeqie (even sidecarfiles==NULL has happened due to the
file grouping issues), and the bugs that mess with the FileData objects
are elsewhere in the code, not in the unref method.
ref0 should not happen. The only possible handling in unref function is to
write an error message and crash.
There may be some missing ref/unref calls in the code but this is fixable. At
the moment I don't think we should change the infrastructure.
I'm more concerned about too many unref calls _and_ unref calls for
invalid FileData pointers. That users sometimes manage to crash Geeqie
with the fd-magick=0x12345678 assertion failing is evidence of either
an unref of freed FileData or memory corruption. Currently I'm trying out
a simplified ViewFile tree lister in an attempt at tracking down further
file_data_unref breakage.
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] On refcounting
On Wed, 04 May 2011 16:30:44 +, OS wrote:
That said, I imagine that we'd be better off just always holding a ref
for every FileData in the current directory. On my machine, a FileData
is 176 bytes and a GList is 24 bytes, so for a directory of 20,000
images, we'd be spending 3.8MB holding FileDatas. That's nothing.
Thoughts?
FWIW, and considering that the current refcounting in Geeqie is
troublesome, you've got my blessing. :-) I'm all for a central list of
the current directory's file data objects, with added maintenance
structures on top of that.
Even with the couple of patches I've added to the tracker, there's at
least one code path that sometimes (but rarely) unrefs FileData and crashes.
One fundamental problem I see is that the code works on plain C pointers
to FileData structs, which may point at freed memory. With unref calls
spread through-out the code and g_lists of ptrs in some places, that
simply bears the risk that unref and g_list remove can get out of sync.
Additionally, the FileData unref method is questionable already (not just
due to its fd-magick checking and special handling of child nodes), since
for example it does
fd-ref--;
if (fd-ref == 0)
{
/* decide whether to file_data_free() or return earlier */
}
return;
and hence doesn't cover the case that ref0, and the responsibility to
drop ptrs to freed FileData from any lists or locals, is not within this
method.
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] grouping with darktable xmp files
On Thu, 14 Apr 2011 23:32:16 +0200, VN wrote: The current algorithm for grouping is in filedata.c - function file_data_set_path() decides, which part of the path is the basename and which is the extension (but I think that some other parts of code expects strrchr(), this should be checked) - function file_data_check_sidecars() groups the files and decides which is the main file and which are sidecars - function filelist_read_real reads a directory and groups the files (through file_data_new_local() and file_data_check_sidecars()) - there is another code path for individually opened files (from commandline, dragdrop, etc.) - file_data_check_sidecars() calls check_case_insensitive_ext(). This code path is a problem for longer extensions and should be probably rewritten to use readdir too. Ideas for improvements or rewrite of the algorithm are welcome. Anything that will resolve the remaining issues with file grouping would be great. check_case_insensitive_ext() causes breakage anyway: http://sourceforge.net/tracker/?func=detailaid=3201373group_id=222125atid=1054682 And the hard to reproduce http://sourceforge.net/tracker/?func=detailaid=3115437group_id=222125atid=1054680 [ filedata.c:693:file_data_unref_debug: assertion failed: (fd-magick == 0x12345678) ] is likely related to file grouping, too, as a recent bug reporter has mentioned using JPG+CR2 files. I probably will read through more of the code, such as view_file_list.c and vflist_setup_iter_recursive() where it crashes upon refreshing the file list tree view, but proof-reading activity like that isn't easy (especially not if the crash may only be a side-effect of something having gone wrong elsewhere). I'd favour a single readdir for getting the current list of files, and then do only in-memory processing of that list with whatever techniques may be helpful to find file groups (e.g. basename dictionary). -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Revisiting file_data_free: assertion failed: (fd-sidecar_files == NULL)
On Sat, 05 Mar 2011 18:49:50 +, Omari wrote: ERROR:filedata.c:676:file_data_free: assertion failed: (fd-sidecar_files == NULL) This has been encountered during loading images from an SD card. I don't think it's ever legitimate for file foo.jpg to have a sidecar foo.JPG, even on a case-sensitive filesystem. So doing a check in file_data_check_sidecars() sounds reasonable. I wouldn't add extra checks in file_data_unref() unless they are guaranteed to be correct for all filesystems (since it is definitely valid for foo.jpg and foo.JPG to _exist_, and we don't want to end up with memory/resource leaks in that case). Okay. I've only thought about ways to handle (and prevent) the special case where the file path of a parent and one of its childs would match during case-insensitive comparison. Meanwhile I've revised the patch. Bug reporter has found another related issue, which required patching also the function that does the fstat check for a generated list of file extensions. If one starts Geeqie with a file arg, such as the path to a .CR2 file that would become a sidecar file, the fstat would succeed for all the generated mixed-cased permutations of .JPG. That resulted in the same fatal assertion crash. The patch has been submitted to the project's Patch tracker. -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
[Geeqie-devel] Revisiting file_data_free: assertion failed: (fd-sidecar_files == NULL)
Hello everyone! This post is related to Geeqie crashing in an assertion in file_data_unref (see subject line). In addition to perusing more of the source code, I've received helpful --debug output from a bug reporter, who can reproduce the issue with a few attempts, while I don't manage to reproduce it: filedata.c:718: file_data_unref: deleting '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.JPG', parent '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.jpg' ** ERROR:filedata.c:676:file_data_free: assertion failed: (fd-sidecar_files == NULL) This has been encountered during loading images from an SD card. As one can see, it added a file (*.JPG) as its own sidecar file (*.jpg), and file_data_unref cannot cope with that. This is because in filedata.c file_data_check_sidecars() and check_case_insensitive_ext() a case-insensitive fstat is performed for files with a generated list of potential sidecar file name extensions. This gives wrong results on a case-insensitive file-system and apparently adds .jpg as a sidecar file for .JPG. layout.c:2204: 0.341570 (+0.033411) layout_new: end filedata.c:390: file_data_new: '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.JPG' 1 0 filedata.c:390: file_data_new: '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.JPG' 0 0 filedata.c:655: file_data_ref (2): '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.JPG' @ filedata.c:398 filedata.c:428: file_data_pool hit: '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.JPG' filedata.c:390: file_data_new: '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.JPg' 0 0 filedata.c:390: file_data_new: '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.JpG' 0 0 filedata.c:390: file_data_new: '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.Jpg' 0 0 filedata.c:390: file_data_new: '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.jPG' 0 0 filedata.c:390: file_data_new: '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.jPg' 0 0 filedata.c:390: file_data_new: '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.jpG' 0 0 filedata.c:390: file_data_new: '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.jpg' 0 0 filedata.c:390: file_data_new: '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.CR2' 0 0 filedata.c:390: file_data_new: '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.Cr2' 0 0 filedata.c:390: file_data_new: '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.cR2' 0 0 filedata.c:390: file_data_new: '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.cr2' 0 0 As a work-around, I've inserted a file ext comparison directly in file_data_check_sidecars(), but I could imagine adding another one in file_data_unref(). What do you think? Regards, Michael -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] recommended version?
On Sun, 12 Jul 2009 20:00:56 -0400, Greg wrote: In a directory with ~600 NEFs, deleting an image is taking 20 seconds of CPU time. I am running 1.0alpha3 which is in pkgsrc. Rather than debug this I thought I should get current. What is the current recommended version for users? Is it the code at svn ls https://geeqie.svn.sourceforge.net/svnroot/geeqie/tags/GEEQIE_1_0_BETA2 or the trunk, or something else? If the current recommended version for users (as opposed to developers) isn't a released tarball, what's the plan for getting back to normal? Since Geeqie has not seen a final release yet, I assume that the most recently released beta2 tarball is what users shall evaluate. It is important to find as many problems as possible prior to preparing a final release. alpha3 contains bugs, some which are fixed by beta2, but beta2 is not bug-free either. In particular, there's a crash related to letting Geeqie work in a directory tree that is modified by an external program (no backtrace yet). When deleting pictures, I've only noticed that since beta2 Geeqie can run into problems while syncing the directory contents for the folder view. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] Help on compilation problem
On Wed, 18 Mar 2009 10:40:24 +0100, Vladimir wrote: I think that glib is not detected correctly and then it is no surprise that GTK fails. Well, the detection could run an existance-check like pkg-config --exists glib-2.0 before continueing with undefined variables that lead to syntax errors. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] munmap_chunk(): invalid pointer - with backtrace
On Sat, 7 Feb 2009 22:13:01 +0100, Vladimir wrote: I think that I have reproduced it. It happens when Geeqie exits with unsaved metadata for exactly one file, in default configuration. Good description. In alpha3 that gives a segfault: (gdb) bt #0 0x00d94312 in free () from /lib/libc.so.6 #1 0x005118c6 in g_free () from /lib/libglib-2.0.so.0 #2 0x080db6fe in remote_close (rc=0x83cf760) at remote.c:353 #3 0x080b269d in exit_program_final () at main.c:580 #4 0x080b28f5 in exit_program () at main.c:661 #5 0x080a53a1 in layout_delete_cb (widget=0x81b4800, event=0x84424f0, data=0x81b4200) at layout.c:1945 [...] The order of callbacks after saving the metadata was wrong and some pointers were freed twice. Revision 1385 should fix it. With that change applied, the segfault is gone. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] munmap_chunk(): invalid pointer - with backtrace
On Fri, 6 Feb 2009 11:02:26 +0100, Vladimir wrote: On čt 5. února 2009, Christopher Beland wrote: On Thu, 2009-02-05 at 09:48 +0100, Michael Schwendt wrote: Running debuginfo-install geeqie would be needed to install the -debuginfo packages that would complete the missing details in this backtrace ( http://fedoraproject.org/wiki/StackTraces ). Highly recommended also in case you can reproduce such a problem. geeqie-debuginfo-1.0-0.13.alpha3.fc11.x86_64 was installed at the time the backtrace was generated. If the crash is reproducible, it should be simple to gdb geeqie and get a good backtrace in there. Does anybody have an idea how this could happen? The only explanation I can think of is a broken debuginfo package. Note that the backtrace did not contain any details for gtk2, glib2, glibc either. And it's Fedora Development, btw. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
Re: [Geeqie-devel] munmap_chunk(): invalid pointer - with backtrace
On Wed, 04 Feb 2009 17:25:41 -0500, Christopher wrote: I'm not sure exactly when it happened, but I found this on my terminal after viewing an image, using the metadata editor, and looking at metadata preferences. *** glibc detected *** geeqie: munmap_chunk(): invalid pointer: 0x00451ba0 *** === Backtrace: = /lib64/libc.so.6[0x3c71277f78] geeqie[0x48d507] geeqie[0x466b5d] geeqie[0x466d65] geeqie[0x45a90c] Running debuginfo-install geeqie would be needed to install the -debuginfo packages that would complete the missing details in this backtrace ( http://fedoraproject.org/wiki/StackTraces ). Highly recommended also in case you can reproduce such a problem. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
