Segmentation fault on postgresql_adapter.rb:607

Issue #135 resolved
Frederico Araujo created an issue

Hi, i'm having segmentation fault when running PG with in a threaded environment with celluloid and sidekiq gems.

Here is the trace for the segmentation fault:

it was also reported here:

gems: celluloid 0.11.1, timer, sidekiq 2.1.0

Sorry if cant give a better reproducible description. let me know what I can do to help debug it.


Comments (20)

  1. Lars Kanis

    Hi @Frederico Araujo , looking at the backtrace, this is a usual use case for the pg-gem. There is obviously nothing fancy, I could try to reproduce the issue. So from my point of view, it is essential to get some code to reproduce the crash.

    You could also post the output of the process started per valgrind.

  2. Michael Granger repo owner
    • changed status to open

    I agree with Lars; without some code to reproduce the crash, I don't think we'll be able to figure out where the segfault is coming from. Output from valgrind or a 'bt full' from gdb would help a lot.

  3. Gary Weaver

    (sorry for attaching twice- had entered above and next to comment- is wierd that it lets you do that)

  4. Gary Weaver

    Attaching sample database.yml, sample schema creation SQL w/info on how to populate/how much to populate, sample model that should cause issue w/pg 0.14.0, Postgres 9.1.3 (latest postgresql from brew), ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-darwin11.4.0], Rails 3.2.6, OS X 10.7.4.

    Sorry, this will probably take some work to make anything useful out of it.

  5. Michael Granger repo owner

    @garysweaver: No problem! Thanks for going through the effort of gathering backtraces and examples! Every little bit of evidence helps! I'll look at trying to replicate this when I get to work.

  6. Gary Weaver

    Attaching SQL to create and example model definitions of a few more models showing the same issue. All tables have more than 1 million rows and trying to do a .all on the model, so I think to replicate you might have to try loading a similar amount of data via .all.

  7. Michael Granger repo owner

    Additional fixes for PG::Result#values and #column_values.

    - Revert the row-building loop of Result#values to use the heap, too. - Use the heap for building #column_values, too.

    Props to Lars Kanis for figuring out the problem.

    Refs #135, #136, #138.


  8. Michael Granger repo owner

    I've just pushed pg-0.14.1.pre.363.gem, which should fix all the known segfaults. Please test it out in your applications and let me know if still see the problem.

  9. Aaron Cohen

    Sorry, I'm new here: how do I obtain pg-0.14.1.pre ?

    (I'm experiencing this issue, and all my attempted workarounds have failed so far.)

    Preferably, is there any workaround for this bug that I can apply, e.g. by changing the table definition that triggers this bug?

    (Sorry to whine, but learning to use mercurial and figuring out how to build this gem for multiple machine architectures doesn't sound like much fun on my tight schedule.)

  10. Aaron Cohen

    Sweet; thanks!!!!

    Solves the crash too, as well as indicating the cause of the crash - an auto-generated page that I hadn't started editing yet was selecting all rows from a table with hundreds of thousands of rows. My own stupid fault after all. :-)

  11. Michael Granger repo owner

    Thanks for the reply Aaron! Glad it fixed it for you. I haven't heard back from anyone else, but I'm going to push out 0.14.1 anyway. Thanks everyone for helping track this one down.

  12. Log in to comment