search

tbullock / freeswitch-openbsd

OpenBSD shallow fork of FreeSWITCH
4 stars 0 forks source link

Crash on OpenBSD when using internal sqlite hash API on system version of sqlite #1

Closed tbullock closed 11 years ago

tbullock commented 11 years ago

Description

Using system sqlite is crashing FreeSWITCH when trying to insert elements into a hash table.

Possible solutions

  1. Fix sqlite crash
    • This could be difficult since we are segfaulting on code we can't reach
    • Upstream is using internal sqlite API, which is a bit weird, maybe get away from this
  2. Replace with OpenBSD specific ohash
    • Modestly viable option, avoids re-implementation and is part of libc in OpenBSD
    • ohash is not available on other platforms
    • not thread safe, needs protection
  3. Replace with APR hash framework
    • Was originally in FreeSWITCH years ago
    • I'm unsure of the reason this was replaced in the first place, perhaps a good reason
  4. Implement fresh hash table algorithm
    • May/will introduce stability bugs since its new code
    • Removes dependency on external library for hashing
    • Fully portable (maybe push to upstream?)
    • May need re-work of API, perhaps not just a drop in replacement?
tbullock commented 11 years ago

Ok, after further thinking

I am ruling out option 1 since I can't believe that using an internal api is the right way to go. I guess that upstream did this because they pulled sqlite into their tree and figured they were free to use it as they saw fit.

Then option 2, I'm ruling this out too. I'm glad that it is built into libc and is readily usable, however I want to ensure that source changes I make can conceivably be merged back upstream, which is absolutely not going to happen with a unique hash table implementation like ohash.

This leaves 3 and 4.

From an engineering perspective, option 3 is probably the way to go since the code paths have been tested, and it should be relatively straight forward to implement.

Option 4... I am extremely tempted to go down this route, however I think that bowing to the practical engineer in my head, I think the best option is to leave this for another day. I can't see any practical point of implementing a custom hashing function that would outweigh the benefit of using the already implemented version in apr back into the code.

So option 3 it is, re-integrating apr hash table into freeswitch.

tbullock commented 11 years ago

rewrote switch_core_hash.c to use the apr hash table functionality.

Should be, effectively, a silent swap-out.

This gets us a heck of a lot further into the startup process.