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?
> 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.
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.
> (Sorry, I'm the builder not the developer.) I never encountered this error
> myself.
> In Hugin->Preferences->General you can set the image memory buffer. By
> default it's set to 75 MB. Could you try again with something like
> 150-200MB?
Something like that would have been my first
suggestions, too.
(1) Increase the process' virtual memory.
Use 64bit?
(2) Try both versions of Enblend with and
without image cache. (Currently only the
staging branch supports both.) Even though I
doubt switching versions will help.
At source-code level:
(3) Replace the allocations in "mask.h" and
"nearest.h" with calls to boost::pool.
Maybe even more changes are needed. We are
using pooled memory already for the image
cache, so you won't introduce a new
dependency.
/Chris
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
