<div dir="ltr"><div>I can't repro the crash replacing my <font face="monospace, monospace"><span style="font-size:12.8px">cycles_</span></font><span style="font-size:12.8px"><font face="monospace, monospace">standalone.cpp </font></span>with this code. If the full version works then you might be able to find the cause by progressively eliminating code.</div><div><br></div><div>Have you tried adding back <font face="monospace, monospace">util_logging_init()</font> and <font face="monospace, monospace">path_init()</font><font face="arial, helvetica, sans-serif">? These are required for correct operations.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">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 </font><span style="font-size:12.8px"><font face="monospace, monospace">__libc_start_main</font> and </span><span style="font-size:12.8px"><font face="monospace, monospace">__GI_exit </font></span>so that would be odd.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 27, 2017 at 9:26 PM, Gareth Morgan <span dir="ltr"><<a href="mailto:garethmorgan1977@gmail.com" target="_blank">garethmorgan1977@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>This is at <span style="background-color:rgb(240,247,255);color:rgb(0,0,0);font-family:Consolas,"Lucida Console",monospace;font-size:12.8px">5d0d9687ace6b07f42a153db129<wbr>4669b46fedd15 on Ubunty 14.04, with GPU, CUDA, and MULTI disabled. The full app still works fine (you can replace </span><font color="#000000" face="Consolas, Lucida Console, monospace"><span style="font-size:12.8px">\src\app\</span></font>cycles_<wbr>standalone.cpp with the attached to repro the crash).</div><div><span style="background-color:rgb(240,247,255);color:rgb(0,0,0);font-family:Consolas,"Lucida Console",monospace;font-size:12.8px"><br></span></div><div>So what else needs to happen in an Cycles application to avoid the globals getting trashed in this way?</div><div><br></div><div>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)</div><div><br></div><div><br></div><div><br></div><div>Program received signal SIGABRT, Aborted.</div><div>0x00007ffff6417c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/<wbr>linux/raise.c:56</div><div>56 ../nptl/sysdeps/unix/sysv/<wbr>linux/raise.c: No such file or directory.</div><div>(gdb) bt</div><div>#0 0x00007ffff6417c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/<wbr>linux/raise.c:56</div><div>#1 0x00007ffff641b028 in __GI_abort () at abort.c:89</div><div>#2 0x00007ffff6410bf6 in __assert_fail_base (fmt=0x7ffff65613b8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=<wbr>0x326a290 "!ret", file=file@entry=0x326a1d0 "/usr/include/boost/thr</div><div>ead/pthread/condition_<wbr>variable_fwd.hpp", line=line@entry=81, function=function@entry=<wbr>0x326a800 <boost::condition_variable::~<wbr>condition_variable()::__<wbr>PRETTY_FUNCTION__> "boost::condition_variable::~<wbr>conditi</div><div>on_variable()") at assert.c:92</div><div>#3 0x00007ffff6410ca2 in __GI___assert_fail (assertion=0x326a290 "!ret", file=0x326a1d0 "/usr/include/boost/thread/<wbr>pthread/condition_variable_<wbr>fwd.hpp", line=81, function=0x326a800 <boost::condition_vari</div><div>able::~condition_variable()::_<wbr>_PRETTY_FUNCTION__> "boost::condition_variable::~<wbr>condition_variable()") at assert.c:101</div><div>#4 0x0000000003181eb0 in boost::condition_variable::~<wbr>condition_variable (this=0x37faee0 <ccl::TaskScheduler::queue_<wbr>cond>, __in_chrg=<optimized out>) at /usr/include/boost/thread/<wbr>pthread/condition_variab</div><div>le_fwd.hpp:81</div><div>#5 0x00007ffff641d1a9 in __run_exit_handlers (status=0, listp=0x7ffff679f6c8 <__exit_funcs>, run_list_atexit=run_list_<wbr>atexit@entry=true) at exit.c:82</div><div>#6 0x00007ffff641d1f5 in __GI_exit (status=<optimized out>) at exit.c:104</div><div>#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</div><div>fffdf38) at libc-start.c:321</div><div>#8 0x000000000056ba7c in _start ()</div><div><br></div></div>
<br>______________________________<wbr>_________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/bf-cycles" rel="noreferrer" target="_blank">https://lists.blender.org/<wbr>mailman/listinfo/bf-cycles</a><br>
<br></blockquote></div><br></div>