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.
Why not just use Mongrel[1]?
It’s pure ruby like Webrick and very fast.
hth,
Stephen
[1] http://mongrel.rubyforge.org/faq.html
Stephen Caudill wrote:
Why not just use Mongrel[1]?
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.”
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 4/14/06, Bryan D. [email protected] 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 4/14/06, Bryan D. [email protected] 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/default.mspx 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 
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 4/14/06, Bryan D. [email protected] 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
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.
Patrick H. wrote:
On 4/14/06, Bryan D. [email protected] 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?
Hmm… MySQL.so compiled on a WinXP box?
On 4/15/06, Bryan D. [email protected] 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
Corey L. wrote:
Hmm… MySQL.so compiled on a WinXP box?
That’s my guess. It always works for me on my WinXP laptop.