Just an update. I was the one who contacted George about getting the sample files. I've done the merge several times to make sure it wasn't tester error, with both x64 and win32 versions. The x64 I made by hand, while the win32 versions I used from Ad's most recent weekly installer build. Both successfully executed a number of test cases without any errors. I've tried without specifying -m, by specifying -m 1024, -m 2048, and (for the x64 build) -m 4096.
Having looked at the strace, it looks like the place where things start to get all crazy is right near/after vigra::CachedFileImage<PIXELTYPE>::swapOutBlock() / vigra::CachedFileImage<PIXELTYPE>::getLinePointerCacheMiss() / vigra::CachedFileImage<PIXELTYPE>::initTmpFile() It should be noted that these methods have different code paths depending on if they're running on Win32 or not (per the ifdef), so that may be related to why I'm unable to reproduce it. If someone who is building binaries wants to strip out some of the comments in those functions, which should increase the debug chatter, it might help. Then again, I could be totally off here as to where the real error is. If I were a betting man/a man prone to donning tinfoil hats (which I am...), I'd be curious to check out getLinePointerCacheMiss(), and the variables blockNumber, firstLineInBlock, numLinesInBlock, and pixelsToRead. If there somehow ended up some over/underflow errors there, and if (blockInFile_[blockNumber]) returned false, then std::uninitialized_fill_n ends up getting called. n, in this case, is pixelsToRead. The result *could* be what is described here, in that it then goes buck-wild on allocation. Judging by the number of calls to brk (12679, give or take a few), I'd set a watchpoint around that code, and see if anything gets crazy. That's just my guess :) It wouldn't hurt for somebody to cout some debug spam for those variables and rebuild enblend/enfuse, if attaching gdb is too much of a pain. For those following, the calls to brk/mmap come from dmalloc, specifically heap.c, under heap_extend. I'm guessing this is being called by the uninitialized_fill_n (STLPort -> _unitialized.h -> __uninitialized_fill_n -> __ufill_n), which is calling the constructor of PIXELTYPE to initialize the pixels (_construct.h -> _Param_Construct -> _Param_Construct_aux) > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of grow > Sent: Monday, May 11, 2009 4:15 PM > To: hugin and other free panoramic software > Subject: Re: hugin-mac-0.8 RC1: enblend compiled against dmalloc (was: > [hugin-ptx] Alpha Channel Masking) > > > Harry, > > My Mac is an old twin processor G5 with 5.5Gb of RAM. So it has the > potential for 64 bit operation. But it is still running MacOSX > 10.4.11 > > I have the disc here for 10.5 and have been meaning to install it for > some time ... but have not yet got around to it. > > This might just be the incentive I have needed to get 10.5 installed > - but the weather here is good and I am on an outdoor photo shoot > tomorrow and Wednesday so ... it will probably be the weekend before > any software installation happens. > > all the best > > George > > On May 11, 7:28 pm, Harry van der Wolf <[email protected]> wrote: > > George and others, > > > > There are two options to try 64bit on OSX > > *Option 1*: (Download again and) use the official 0.7.0 version from > > sourceforge. That one is a 32bit/64bit version. A G5 is a 64bit > machine (the > > only ppc 64bit machine). However, it will only work as 64bit* if you > have > > Leopard!* Tiger is only 32bit, no matter which platform you run it > on. > > Every Intel core2 or newer is 64bit. With Leopard that will enable > 64bit > > applications. > > > > *Option 2:* > > On my website you can still find the 64bit stand-alone enblend > version from > > svn 3176 <http://panorama.dyndns.org/download.php?id=241>. > > If you download that one and copy it in the latest build, you could > try that > > one too. > > (Actually the only binary that really benefits from 64bit is enblend, > so you > > might give that a try) > > > > To get it in one of the latest hugin.app's do the following: > > - right-click (ctrl-click) the Hugin.app. Select "Show package > content" from > > the popup. > > - Move down into "Contents -> Resources" > > There you will find HuginStichProject.app. > > - Right-click (ctrl-click) the HuginStichProject.app and select again > "Show > > package content". > > - Move down into "Contents -> MacOS". > > Copy the downloaded 64bit enblend over that existing enblend. > > *Note: Again, only within Leopard and only on G5 or Intel Core2 (or > newer) > > 64bit applications will run as 64bit* > > > > Note 2: The malloc libs on Leopard are 32bit/64bit libraries. In > combination > > with a 64bit enblend (on Leopard) it will run in 64bit mode. > > > > Harry > > > > 2009/5/11 grow <[email protected]> > > > > > > > > > Hi Folks, > > > > > Another person - Ryan - downloaded the problematic project and > ran > > > it on a 64 bit Windows system and it worked!. > > > He had also added options: > > > -v - v (for extra commentary) and -m 4096 > > > > > He is going to post some details of the results he got along the > way. > > > > > So I tried again on my Mac OS X 10.4 PowerMac G5 system adding the > > > options: > > > -v -v -m 4096 > > > and of course it crashed again but provided some extra reporting - > > > see below. > > > > > Ryan is going to try again on a 32 bit Windows system to see > whether > > > that is the crucial difference. > > > > > all the best > > > > > George > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
