On Wed, Jan 02, 2002 at 07:36:35PM -0500, Michael O'Donnell wrote: [snip]
> Let me assure you that I don't know sh*t about > Cold Fusion, Sablotron, Apache or whatever, but I Neither do I, but I'm learning... > know a bit about systems-software and debugging. I used to develop code, but it's been a long time since I've done anything of significant size. And all I really ever developed in was C (some Ada, Pascal, and FORTRAN as well). > Some preliminary questions: > > - Is the failing module part of some nasty-huge > whole or soem smaller thing that gets launched > in response to some input? Sablotron is a high performance XSLT processor that uses the expat xml parsing library. More info is available at the Ginger Alliance at http://www.gingerall.com/. It's easy enough to separate out that we even have a main() method that just calls it with command line arguments. It works from the command line, but not when called from Cold Fusion. (CF is basically just a super expensive, really dumbed down web scripting language. It runs it's own server processes, and ties into apache with the standard DSO interface [mod_coldfusion.so].) > - Can you substitute some other program for the > failing module? Not really. The code looks relatively simple. In fact, it looks like only a little more than wrapper to turn it into a Cold Fusion custom tag. > - Can you capture whatever data are being fed > to the failing module? We have that information, and it works on the command line. > - Can you pause the system immediately prior to > it launching the failing module? Not unless I'm REALLY quick with the keyboard. :-) Just kidding. Not really. > - Can you run the failing module under GDB? I'm not sure what process to run it on. The cfserver, httpd? Each have multiple copies, it's hard to figure out which one. > - Have you got any recreational drugs? Ah, now you're onto something! Caffeine is the strongest I've got, though. Wait, maybe there's some Elmer's Glue in the...never mind. I forgot to mention that I did do a Google search on 'sablotron expat apache segfault' and found lots of references to this exact type of problem. The results seem to universally point to multiple copies of the expat processor due to the fact that many products (apache included) include their own copy of expat. Depending on the version, whether it's linked statically or dynamically and anything else you are using that needs expat, there can be serious conflicts. It has something to do with instantiating the parser multiple times and then the code that makes the call to the parser doesn't know which instance to call. Something like that. Anyhow, based on what I read, it appears that I've got everything set right. Red Hat's apache 1.3.22 update links dynamically to the external expat. So does the 0.71 rpm of sablotron from the Ginger Alliance. Even the perl-XML-Parser is linked dynamically, though we don't use that. The only thing I can think of that might not be is php (which we use a small bit of), but we don't even use any of the XML stuff in php and I don't think we've even reached the point where php would be loaded. I may be wrong, though, as I know little about the inner workings of apache. -- -Paul Iadonisi Senior Systems Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
