I'm using Ruby 1.8.4 on a Windows 2000 machine. When running anything more than a trivial application, I experience frequent segmentation faults in completely random places. I've read some blogs and the such that indicate it has something to do with MySQL libraries. It all seems pretty silly, since I have a WinXP laptop which runs my apps with no issues at all. Does anyone know what it is about Win2k that causes this sort of behavior? I'm really getting tired of doing all my development on my laptop.
on 2006-04-15 01:15
on 2006-04-15 02:28
Why not just use Mongrel? It's pure ruby like Webrick and very fast. hth, Stephen  http://mongrel.rubyforge.org/faq.html
on 2006-04-15 03:14
Stephen Caudill wrote: > Why not just use Mongrel? > > It's pure ruby like Webrick and very fast. I believe Mongrel has native C code in there, but the gem package for win32 offers a precompiled version. Curious to learn, though, about migrating WEBrick-based apps to Mongrel. I've been developing on my WinXP laptop for about 6 months now, and prior that, a Win2K laptop. I have a desktop PC, but sitting on the recliner or the beanbag chair is more comfy. I've not had WEBrick issues on WinXP or Win2K, though I don't use Ruby 1.8.4 much on Win2K. My Win2k desktop runs some background jobs, and at least one (Catapult) is using WEBrick, but nothing too industrial. And no MySQL + Ruby 1.8.4. -- James B. "In Ruby, no one cares who your parents were, all they care about is if you know what you are talking about." - Logan C.
on 2006-04-15 04:20
Actually, I ran on 1.8.2 for a long time, too. The errors had exactly the same symptoms. I'm really disappointed that the various Mysql libraries that offer to fix this problem don't seem to get it fixed. Would it help if I somehow figured out how to compile my own, which would be linked against the libraries on my machine? Could that be the issue? I'm loathe to try and compile stuff where I don't have to (I like Ruby for a reason...), but I'm getting a little irked that I have to forgo using my nice desktop with dual monitors and use my laptop instead.
on 2006-04-15 06:07
On 4/14/06, Bryan D. <email@example.com> wrote: > > -- > Posted via http://www.ruby-forum.com/. > > Mongrel is great, but this problem sounds like a mysql driver issue more than web brick. Is it possible to get a stack trace (OS not Ruby) when it segfaults? My guess is that the build of the binary mysql driver does not match the build of the ruby binary (difference in compiler version, etc). You could try building everything yourself or try grabbing a complete set like instant rails. pth
on 2006-04-15 06:12
Patrick H. wrote: > On 4/14/06, Bryan D. <firstname.lastname@example.org> wrote: >> >> -- >> Posted via http://www.ruby-forum.com/. >> >> > > Mongrel is great, but this problem sounds like a mysql driver issue > more than web brick. Is it possible to get a stack trace (OS not Ruby) > when it segfaults? My guess is that the build of the binary mysql > driver does not match the build of the ruby binary (difference in > compiler version, etc). You could try building everything yourself or > try grabbing a complete set like instant rails. > > pth How would I go about getting an OS stack trace? Do you have any experience doing that on Windows?
on 2006-04-15 06:47
On 4/14/06, Bryan D. <email@example.com> wrote: > > when it segfaults? My guess is that the build of the binary mysql > Posted via http://www.ruby-forum.com/. > > Been a long time since I used 2000, but do you have Visual C or any other just in time debugger? Most of those allow you to catch a segfaulting processes and grab the stack trace. I know under XP you can actually get that info from the XP error dialog that XP wants to send to Microsoft, but I think they added that for XP. Worst case go to http://www.microsoft.com/whdc/devtools/debugging/d... and grab windbg.exe and attach it to ruby.exe after you start webrick. We don't need much detail, if it is dying in mysql.so or something similar then you know it is the mysql driver, etc. Again my expectation is that you are using some binary extension that was compiled just a little bit differently than the version of ruby you are using. For example one was compiled using VC6 and the other with VC.NET (or whatever they are calling it now). This often works, but it also can lead to difficult to diagnose bugs in discrepancies between the run time libraries (C not Ruby). Good luck pth p.s. I have run webrick and mongrel with mssql and postgres binary drivers under Win2000 (server) without any trouble (not that I was happy about it :-)
on 2006-04-15 07:00
According to the VS.NET debugger, this is the call stack. Does this look like what you were looking for? There's no debug symbols, so all the functions are obfuscated. Is that going to make this more difficult? > NTDLL.DLL!77f9193c() NTDLL.DLL!77fb2a30() NTDLL.DLL!77fb28b1() NTDLL.DLL!77fa63a5() NTDLL.DLL!77fa64af() msvcrt-ruby18.dll!1000b144() msvcrt-ruby18.dll!1000aebb() msvcrt-ruby18.dll!1000abe9() NTDLL.DLL!77fcb301() NTDLL.DLL!77fcb4be() NTDLL.DLL!77fcb618() msvcrt-ruby18.dll!1003b234() msvcrt-ruby18.dll!1000646f() NTDLL.DLL!77f877e9() NTDLL.DLL!77fcd981() NTDLL.DLL!77fcba2b() NTDLL.DLL!77fcb9b1() msvcrt-ruby18.dll!100056d6() NTDLL.DLL!77f89d99() KERNEL32.DLL!7c5aa8ba() msvcrt-ruby18.dll!1000c8e3() KERNEL32.DLL!7c5aa942() KERNEL32.DLL!7c58641c() msvcrt.dll!78012d3d() msvcrt-ruby18.dll!1000b524() msvcrt-ruby18.dll!1005f1f3() msvcrt-ruby18.dll!1000d706() msvcrt.dll!78001532() NTDLL.DLL!77f89d99() KERNEL32.DLL!7c5aa8ba() NTDLL.DLL!77fcb0ff() KERNEL32.DLL!7c5aa942() KERNEL32.DLL!7c58641c() msvcrt.dll!78007e4f() NTDLL.DLL!77f8a922() KERNEL32.DLL!7c596a0f() msvcrt.dll!78013409() msvcrt.dll!78012eb5() msvcrt.dll!78012e81() msvcrt.dll!78007cd8() msvcrt.dll!78007ce7() msvcrt.dll!7800d056() msvcrt.dll!7800695c() msvcrt-ruby18.dll!10022034() NTDLL.DLL!77fcaeed() NTDLL.DLL!77fcb4be() NTDLL.DLL!77fcb618() msvcrt.dll!780242ea() msvcrt-ruby18.dll!1000c8e3() msvcrt-ruby18.dll!1000646f() msvcrt-ruby18.dll!100490ad() msvcrt.dll!7800c16a() ruby.exe!00401149() msvcrt.dll!7800bdb5() NTDLL.DLL!77fbb272() NTDLL.DLL!77facc28() msvcrt-ruby18.dll!10020d99() msvcrt-ruby18.dll!10045c63() msvcrt-ruby18.dll!10045d19() msvcrt-ruby18.dll!10056d94() msvcrt-ruby18.dll!10057a80() NTDLL.DLL!77f91bc6()
on 2006-04-15 07:23
On 4/14/06, Bryan D. <firstname.lastname@example.org> wrote: > msvcrt-ruby18.dll!1000aebb() > msvcrt-ruby18.dll!100056d6() > NTDLL.DLL!77f89d99() > msvcrt.dll!78007cd8() > msvcrt-ruby18.dll!100490ad() > NTDLL.DLL!77f91bc6() > > -- > Posted via http://www.ruby-forum.com/. > > Ok I admit I did not see what I was expecting, but let's look at things statically. Since you have vs.net, you should also have dumpbin. First look at: dumpbin /dependents ruby.exe then look at dumpbin /dependents mysql.so In particular we want to verify that they are using the same runtime dll's (probably msvcrt.dll which is from vc6). If they are different that is probably the problem. pth
on 2006-04-15 07:43
dumpbin /dependents ruby.exe: File Type: EXECUTABLE IMAGE Image has the following dependencies: msvcrt-ruby18.dll MSVCRT.dll Summary 1000 .data 1000 .rdata 1000 .rsrc 1000 .text dumpbin /dependents mysql.so Dump of file mysql.so File Type: DLL Image has the following dependencies: msvcrt-ruby18.dll WS2_32.dll KERNEL32.dll ADVAPI32.dll Summary DC000 .data B000 .rdata 4000 .reloc 1000 .rsrc 3D000 .text That indicates they aren't sharing the same dependencies, right? BTW - thanks for taking the time to help me so significantly.
on 2006-04-15 10:59
Hmm... MySQL.so compiled on a WinXP box?
on 2006-04-15 18:30
Corey L. wrote: > Hmm... MySQL.so compiled on a WinXP box? That's my guess. It always works for me on my WinXP laptop.
on 2006-04-15 23:07
On 4/15/06, Bryan D. <email@example.com> wrote: > Corey L. wrote: > > Hmm... MySQL.so compiled on a WinXP box? > > That's my guess. It always works for me on my WinXP laptop. > > -- > Posted via http://www.ruby-forum.com/. > > Actually there is no smoking gun here -- the only dependencies are for things that are integrated into ruby or part of win32 (that should work fine between 2000 and XP). Another guess is that the mysql.so is built with the runtime library statically linked (note the lack of run time library dll). If that is the case things are messy. pth