random crashes on Win7 x64 #27
Comments
|
Yes, I noticed this as well. Unfortunately the Windows C backtraces are
quite useless, but I'll try it on Linux with valgrind.
I got crashes at application shutdown only, so far. Your report sounds like
you're getting them earlier - that's not good - I'll have a look at it on
the weekend!
|
|
Hi Lars, any updates on this issue? -andy |
|
@andyschmidt Sorry, I'm currently very busy with work, so that I had to defer this. But thank you for the reminder! I'll try to have a look at it next week. |
|
Hi Lars, first of all I wish you a happy new year! I just installed fxruby (watobo) on a fedora amd64 system and it's crashing all the time. Is there a chance that you get it fixed in the near future? Otherwise I have to do a rollback with the watobo project. -andy |
|
Will have a look at it now (... and postpone PostgreSQL-9.5 additions to pg.gem). |
|
I can not get watobo to crash, by clicking through all the windows and dialogs. Is there any particular sequence I could use? |
|
Could you run watobo with valgrind and post a crash report of valgrind? |
|
Not sure if I did it right ... got different crashes: 1.) 2.) 3.) Hope this helps |
|
@andyschmidt The valgrind stacktraces are very different to the ruby stacktrace above. So this doesn't help me, to figure out the root cause. Vagrind usually reports some invalid reads, before it shows the backtrace. How did you call valgrind and watobo? According to the backtrace without valgrind, the crash then should be some where in FXWindow.Update . Is there a specific action, at which the crash happens? |
|
@larskanis I called valgrind this way: this crash happend after I did a curl request through watobo. |
|
no I got a crash with FX::FXWindow::onUpdate |
|
crasj summary: |
|
Hi Lars, any news on this? |
|
my last crashes on linux (inside a vm) happend always at the same address (0xb). The crashes were happening randomly, without a specific interaction. |
|
The above stack trace looks promising, because it shows, where the illegal access happened, where the memory was free'd and where it was allocated. I'll have a look at it now. It's almost always a GC issue, when ruby crashes randomly. And the fox toolkit isn't built with a GC in mind.... |
|
Damn - I don't get it! The crash happens, because of an event is sent to a FXWindow object, whose target pointer is no longer valid. The target pointer is most likely a FXPseudoTarget object and this is always assigned to an instance variable of the FXWindow object. Therefore ruby usually should not GC the FXPseudoTarget alone without the FXWindow object. However it seems that exactly this happens. The only idea I have, is that the whole FXWindow object is orphaned (and the FXPseudoTarget with it), but ruby chose to free the FXPseudoTarget first, and then went back to ruby code, so that the next event is delivered to an half deleted object. This however shouldn't happen, because any orphaned FXWindow object should decoupled from the message queue. I need a way to reproduce this! Without further possibility to debug it, I fear to be unable to fix this issue. |
|
No good news :( |
|
I guess addChore will work reasonable on MRI, because of MRI's internal locking (GVL). However it is not written to be thread safe on the C++ side. In contrast runOnUiThread is fully thread safe. I did another longer scan and test session with watobo, but it is - well - stable as a rock! This is on native running Ubuntu-15.10 and ruby-2.2.4, installed per rvm. |
|
good to hear that it's stable on your side :) |
|
It's the latest github state. I'm not sure, what I did exactly, but I did various scans on my web applications with watobo. This program is huge - really awesome! And it didn't crash a single time. Maybe it's an issue related to the ruby version. You seem to use ruby-2.0 both on Windows and on Linux. I'll try this version too and maybe also Rubinius, as well. |
|
I tested on ruby 2.2.4 via rvm (Kali 2016) and it's still crashing. I'm using foxlibs 1.6.50 and FXScintilla 2.28.0. To ./configure fxscintilla I use the switch --enable-shared. Are there any differences here? |
|
Hi Lars, any news on this? Ruby Version: 2.2.4 |
Not much. I tested with Rubinius and it was equally stable. It only consumed more memory and felt somewhat slower. I used the fox toolkit and fxscintilla from the Ubuntu-15.10 repository. However thank you for the stack traces based on ruby-2.2! They look very similar. How long do you work with watobo, until it crashes? |
|
Hi Lars, sorry for my late response, I've been on vacation. |
|
mmmhhh ... I could crash it without making a single request through it, just by clicking/switching between plugins, views, etc. (tested on windows) - after I started a new project! |
|
I now removed all addTimeouts and replaced them with a threaded loop which calls runOnUiThread, but without any success. |
|
ok, now I switched back to old-style Timeouts/Chors and FXRuby 1.6.29. |
|
I'm almost sure, that this commit is causing your troubles. I'm still unable to reproduce this on Linux (and Windows isn't very helpful, because I can not debug these kind of issues seriously). If you can find a more minimalist example to get this crash, it would still be useful. |
|
ok, I'll let you know. |
|
I pushed fxruby-1.6.37.rc1 to rubygems.org which should fix this issue. Can you please test against your applications, if everything runs as expected? |
|
@andyschmidt Does fxruby-1.6.37 fix this issue? |
|
Hi I run some some tests on win and linux. got one crash on linux so far ... but it was a different one. no crash on windows :) good job! Thanks a lot! :) |
|
libfox isn't built with garbage collection in mind. This and the additional layer of SWIG makes it very difficult to handle all edge cases of object access and memory handling correctly. Nevertheless I'm quite happy with the current solution. When I started with fxruby internals, I didn't believe that we'll be able to handle these cases cleanly. When I find some free time, I'll have a look at the "crash at exit" issues. Thank you for following up! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When I run watobo with a new version of fxruby on my windows box, watobo is crashing randomly, even without further interaction (after a new project is started).
Here's the crash output:
G:/Projects/watobo/lib/watobo/gui.rb:72: [BUG] Segmentation fault
ruby 2.0.0p647 (2015-08-18) [i386-mingw32]
-- Control frame information -----------------------------------------------
c:0004 p:---- s:0011 e:000010 CFUNC :run
c:0003 p:0097 s:0008 e:000007 METHOD G:/Projects/watobo/lib/watobo/gui.rb:72
c:0002 p:0154 s:0005 E:000348 EVAL watobo_gui.rb:21 [FINISH]
c:0001 p:0000 s:0002 E:00014c TOP [FINISH]
watobo_gui.rb:21:in
<main>' G:/Projects/watobo/lib/watobo/gui.rb:72:instart'G:/Projects/watobo/lib/watobo/gui.rb:72:in `run'
-- C level backtrace information -------------------------------------------
C:\Windows\SysWOW64\ntdll.dll(ZwWaitForSingleObject+0x15) [0x77CBF911]
C:\Windows\syswow64\kernel32.dll(WaitForSingleObjectEx+0x43) [0x75E21194]
C:\Windows\syswow64\kernel32.dll(WaitForSingleObject+0x12) [0x75E21148]
C:\Ruby200\bin\msvcrt-ruby200.dll(rb_vm_bugreport+0xa7) [0x66903317]
C:\Ruby200\bin\msvcrt-ruby200.dll(rb_name_err_mesg_new+0x69d) [0x667C131D]
C:\Ruby200\bin\msvcrt-ruby200.dll(rb_bug+0x2e) [0x667C213E]
C:\Ruby200\bin\msvcrt-ruby200.dll(rb_check_safe_str+0x37a) [0x6688636A]
[0x00401866]
C:\Windows\SysWOW64\ntdll.dll(RtlKnownExceptionFilter+0xb7) [0x77D1344F]
-------------------------------->8-----------------------
Watobo Version: 0.9.22
FXRuby Version: 1.6.33
Fox Version: 1.6.49
Any hints or tips?
If I use an older version of fxruby I get an error that runOnUiThread is an unknown method.
regards,
andy
The text was updated successfully, but these errors were encountered: