Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sighandler_crash after system update #13

Open
rivella50 opened this issue Feb 24, 2015 · 2 comments
Open

sighandler_crash after system update #13

rivella50 opened this issue Feb 24, 2015 · 2 comments

Comments

@rivella50
Copy link

Hi,
on quite an old OS X system (10.6.8) with Ruby 1.8.7 we had a system update last week.
After that search requests with Ferret don't work that well anymore.
After indexing searches get back id's with score of 1.0, where trying to access with that id leads to this error:

StandardError: Exiting on signal %s (%d) occured at <global.c>:423 in sighandler_crash
SIGSEGV
    from /Library/Ruby/Gems/1.8/gems/ferret-0.11.8.5/lib/ferret/index.rb:460:in `[]'
    from /Library/Ruby/Gems/1.8/gems/ferret-0.11.8.5/lib/ferret/index.rb:460:in `[]'
    from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
    from /Library/Ruby/Gems/1.8/gems/ferret-0.11.8.5/lib/ferret/index.rb:452:in `[]'

Other id's still work and deliver correct response.
We have reinstalled ferret 0.11.8.5 with no luck.
In our ruby code we rescue now these errors for still getting back a correct response, but we would still like to know how this problem could be solved.
Thank you!

EDIT: When i perform the search on my local machine with same index, ruby, etc. the same error happens but with this error message:

RangeError: integer 2190371140 too big to convert to `int'
    from /Users/valley/.rvm/gems/ruby-1.8.7-head@xy/gems/ferret-0.11.8.5/lib/ferret/index.rb:460:in `[]'
    from /Users/valley/.rvm/gems/ruby-1.8.7-head@xy/gems/ferret-0.11.8.5/lib/ferret/index.rb:460:in `[]'
    from /Users/valley/.rvm/rubies/ruby-1.8.7-head/lib/ruby/1.8/monitor.rb:242:in `synchronize'
    from /Users/valley/.rvm/gems/ruby-1.8.7-head@xy/gems/ferret-0.11.8.5/lib/ferret/index.rb:452:in `[]'
@jkraemer
Copy link
Owner

What Ruby version are you running with after the system update?

Last time I actively used Ferret several years ago, Ruby 1.8.7 was the only way to run it in a reliable way. Various versions of 1.9 were experiencing problems similar to yours...

On 24 Feb 2015, at 15:35, Valentin Treu notifications@github.com wrote:

Hi,
on quite an old OS X system (10.6.8) with Ruby 1.8.7 we had a system update last week.
After that search requests with Ferret don't work that well anymore.
After indexing searches get back id's with score of 1.0, where trying to access with that id leads to this error:

StandardError: Exiting on signal %s (%d) occured at <global.c>:423 in sighandler_crash
SIGSEGV
from /Library/Ruby/Gems/1.8/gems/ferret-0.11.8.5/lib/ferret/index.rb:460:in []' from /Library/Ruby/Gems/1.8/gems/ferret-0.11.8.5/lib/ferret/index.rb:460:in[]'
from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/monitor.rb:242:in synchronize' from /Library/Ruby/Gems/1.8/gems/ferret-0.11.8.5/lib/ferret/index.rb:452:in[]'

Other id's still work and deliver correct response.
We have reinstalled ferret 0.11.8.5 with no luck.
In our ruby code we rescue now these errors for still getting back a correct response, but we would still like to know how this problem could be solved.
Thank you!


Reply to this email directly or view it on GitHub.

@rivella50
Copy link
Author

It' still 1.8.7:
ruby 1.8.7 (2012-02-08 patchlevel 358) [universal-darwin10.0]
Really strange. I just don't know now what i can do and where the error actually is "generated" (already at indexing level or at search level).
Is there perhaps a test routine a could play through where the error possibly can be determined ?
Thank you for your assistance!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants