The 2014-11-28, Stefan Sperling wrote: > On Wed, Nov 26, 2014 at 10:12:20PM -0700, Ted Bullock wrote: > > On 2014-10-31 2:43 AM, Ted Bullock wrote: > > >- The upstream hashing function uses internal sqlite API calls which I > > >think is dumb; I tried to use the APR hashing api (which at least is > > >public api) but I've done something bad and its segfaulting when exiting > > >the daemon, so I should probably fix that. > > > > This is fixed. Like I said earlier I will probably still re-roll this from > > scratch. > > Have you tried to figure out why the code using apr hash tables > caused a crash? There could be a problem with how the applications > manages apr pools.
Yup, it was my fault and caused by me writing it without being able to test directly. It wasn't until things actually started running (having enough bits built and all symbols supplied) that I could even start to test. The actual fix took about 6 seconds to diagnose once I threw it in the debugger. I just hadn't got to it by the time I wrote that last message at the end of october. > apr is compiled with pool-debugging by default on OpenBSD. > This is to make malloc junking etc. work reliably. Enabling pool > debug is the easiest way of mapping apr pools directly to malloc/free. Neat, that's good to know. I think I saw something about that on tedu's talk at eurobsdcon. As an aside, is sqlite built using base malloc/free or its own internal memory allocator? I noticed tonight that a couple objects returned by sqlite3_mprintf couldn't be freed with free(3), and I had to use sqlite3_free instead (on i386 -current from last week). I didn't really look at it beyond a quick perusal of the online sqlite documentation. -- Ted Bullock
