[Bf-cycles] Strange startup crash in minimal standalone blender app

[Brecht Van Lommel]

I can't repro the crash replacing my cycles_standalone.cpp with this code.
If the full version works then you might be able to find the cause by
progressively eliminating code.

Have you tried adding back util_logging_init() and path_init()? These are
required for correct operations.

To me the backtrace looks like a crash on exit after the main function has
returned. Maybe exit was triggered in some other way, but in the backtrace
there is nothing between __libc_start_main and __GI_exit so that would be
odd.

On Tue, Jun 27, 2017 at 9:26 PM, Gareth Morgan <garethmorgan1977 at gmail.com>
wrote:

> To track down a crash I'm getting my Cycles application I created a very
> minimal version of cycles_standalone.cpp (attached). That does nothing
> except create a context and set progress CB.
>
> The result, weirdly is a crash in the process initialization function (as
> in never gets to the compiled application code at all, never reaches the
> start of the main function ). Looks to be crashing creating a boost
> condition_variable object. I suspect this may be a similar issue to what
> I'm seeing in my app.
>
> This is at 5d0d9687ace6b07f42a153db1294669b46fedd15 on Ubunty 14.04, with
> GPU, CUDA, and MULTI disabled. The full app still works fine (you can
> replace \src\app\cycles_standalone.cpp with the attached to repro the
> crash).
>
> So what else needs to happen in an Cycles application to avoid the globals
> getting trashed in this way?
>
> The actual crash I'm getting in my app is a "free(): invalid pointer"
> error the first time set_status is called (as with this crash I suspect
> this is caused by some global object that was initialized badly in the
> process initialization function)
>
>
>
> Program received signal SIGABRT, Aborted.
> 0x00007ffff6417c37 in __GI_raise (sig=sig at entry=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> 56      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or
> directory.
> (gdb) bt
> #0  0x00007ffff6417c37 in __GI_raise (sig=sig at entry=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x00007ffff641b028 in __GI_abort () at abort.c:89
> #2  0x00007ffff6410bf6 in __assert_fail_base (fmt=0x7ffff65613b8
> "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion at entry=0x326a290
> "!ret", file=file at entry=0x326a1d0 "/usr/include/boost/thr
> ead/pthread/condition_variable_fwd.hpp", line=line at entry=81,
> function=function at entry=0x326a800 <boost::condition_variable::~
> condition_variable()::__PRETTY_FUNCTION__> "boost::condition_variable::~
> conditi
> on_variable()") at assert.c:92
> #3  0x00007ffff6410ca2 in __GI___assert_fail (assertion=0x326a290 "!ret",
> file=0x326a1d0 "/usr/include/boost/thread/pthread/condition_variable_fwd.hpp",
> line=81, function=0x326a800 <boost::condition_vari
> able::~condition_variable()::__PRETTY_FUNCTION__>
> "boost::condition_variable::~condition_variable()") at assert.c:101
> #4  0x0000000003181eb0 in boost::condition_variable::~condition_variable
> (this=0x37faee0 <ccl::TaskScheduler::queue_cond>, __in_chrg=<optimized
> out>) at /usr/include/boost/thread/pthread/condition_variab
> le_fwd.hpp:81
> #5  0x00007ffff641d1a9 in __run_exit_handlers (status=0,
> listp=0x7ffff679f6c8 <__exit_funcs>, run_list_atexit=run_list_atexit at entry=true)
> at exit.c:82
> #6  0x00007ffff641d1f5 in __GI_exit (status=<optimized out>) at exit.c:104
> #7  0x00007ffff6402f4c in __libc_start_main (main=0x56c148 <main(int, char
> const**)>, argc=1, argv=0x7fffffffdf48, init=<optimized out>,
> fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffff
> fffdf38) at libc-start.c:321
> #8  0x000000000056ba7c in _start ()
>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20170627/e981786a/attachment.htm