Harry, Bruno, I have now experimented a bit more with this stitch. Using the preview panel I removed various images and exposure-stack image-triples in turn and re-ran the stitch over and over ... It kept crashing at what looks like the same place UNTIL I removed a particular triple of images. When I put them back in it crashes again.
Now I have looked closely at those three images. Each has an Alpha- channel mask that was created from a "feathered" selection so I think the mask has shades of grey in it, not just black ... is that a known problem? My next plan is to preserve those images in case they are useful evidence for a bug hunter and then replace them by images with a solid black mask ... I'll let you know what happens. all the best George On 20 Apr, 09:45, Harry van der Wolf <[email protected]> wrote: > 2009/4/20 cspiel <[email protected]> > > > > > Harry - > > > > This same error was reported on Newyears day by "nobody" > > (hugin-Bugs-2480029). > > > Despite my request for more info we didn't get it. > > > From the study of the ticket I conclude > > you are talking about a problem with Enblend not > > with Hugin. Right? > > Correct! To end users is is hugin that crashes, be it through enblend or > "whatever else". > > > > > > > > I know there are some "irregularities" with malloc on OSX. > > > Error code 3 means: > > /* The address range specified is already in use, or > > * no address range of the size specified could be > > * found. */ > > > Googling the problem suggests that... > > The implementation of realloc on Darwin never frees memory, so > > when using a large buffer size on incomplete reads you end up > > with lots of small strings that actually take up a large > > allocation. > > In other words the VM sub-system of the OS > > causes the trouble. > > > > Ippei made a hack for it in the scripts we use and he added some (subtle) > > > comments: > > > # hack; AC_FUNC_MALLOC sucks!! > > > mv "./config.h" "./config.h-copy"; > > > sed -e 's/HAVE_MALLOC\ 0/HAVE_MALLOC\ 1/' \ > > > -e 's/rpl_malloc/malloc/' \ > > > "./config.h-copy" > "./config.h"; > > > Cargo cult. > > > It is known that AC_FUNC_MALLOC does not go well > > with cross-compiling, sure. However, the fix the > > rpl_* wrappers should perform has nothing to do > > with OOM conditions. > > > > Maybe by now it hurst more than it helps. > > > Well, at least it gives me a hearty laugh: > > "Fixes" the wrong thing at the wrong place. > > Do you mean that I should remove that "fix" or change it somehow? > > > > > While we are at it: can somebody tell me whether > > I better remove AC_FUNC_MALLOC from > > "configure.in" in the staging branch? Neither > > Enblend nor Enfuse rely directly on the > > preprocessor symbols that the m4 macro > > generates. > > I can't answer that. Maybe Andrew can if he is reading this thread (I now > copied him in) > > Harry --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
