244349 - doesn't finish translation using Babelfish Webservice from English to Japanese/Chinese

Status: RESOLVED FIXED

(Core Graveyard :: Web Services, defect)

Description

[Gashu]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040517
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040517

Browser crashes if I translate using Babelfish Webservice from English to Japanese.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040517

Reproducible: Always
Steps to Reproduce:
1. open http://weblogs.mozillazine.org/doron/
2. choose "Japanese" for "To" field in translation box 
3. click [Go] button.
Actual Results:  
browser crashes

Expected Results:  
browser doesn't crash

Doesn't crash if I translate to "French".

Comment 1

[Gashu]

after rebooting Windows, it doesn't crash but mouse pointer stays wait status.
and it behaves same when I translate from "English" to "Chinese".

maybe it is just taking very long time? I left for 3 minutes but didn't finish
though...

Comment 2

[Gashu]

- reproducible with Mozilla 1.4 release. 
- also an example in DevEdge which should have used to work with 1.4 not working
(both 1.4/1.7).
http://devedge.netscape.com/viewsource/2003/wsdl/01/example.html

so it is probably a problem of BabelFish Webservice itself, assuming they are
not supporting Japanese/Chinese(UTF-8) code translation this time.

INVALID?

Comment 3

[Charles Fenwick]

from my cuurent cvs build on Linux:

#0  0x407e0fa6 in nanosleep () from /lib/i686/libc.so.6
#1  0xffffffd8 in ?? ()
#2  0x407e0dd7 in sleep () from /lib/i686/libc.so.6
#3  0x0806a1a6 in ah_crap_handler(int) (signum=11)
    at /home/clfenwi/moz/mozilla/xpfe/bootstrap/nsSigHandlers.cpp:135
#4  0x41c8dce6 in nsProfileLock::FatalSignalHandler(int) (signo=11)
    at
/home/clfenwi/moz/mozilla/profile/dirserviceprovider/src/nsProfileLock.cpp:209
#5  0x4010d96c in __pthread_sighandler () from /lib/i686/libpthread.so.0
#6  <signal handler called>
#7  0x42e800d3 in WSPCallContext::CallCompletionListener() (this=0xa0ef538)
    at
/home/clfenwi/moz/mozilla/extensions/webservices/proxy/src/wspcallcontext.cpp:319
#8  0x42e7f6ea in WSPCallContext::HandleResponse(nsISOAPResponse*, nsISOAPCall*,
unsigned, int, int*) (this=0xa0ef538, aResponse=0xa3e4a8c, aCall=0xa1517cc,
    status=0, aLast=1, _retval=0x0)
    at
/home/clfenwi/moz/mozilla/extensions/webservices/proxy/src/wspcallcontext.cpp:153
#9  0x42e4bf0c in nsHTTPSOAPTransportCompletion::HandleEvent(nsIDOMEvent*) (
    this=0xa13bc90, aEvent=0xa120ae8)
    at
/home/clfenwi/moz/mozilla/extensions/webservices/soap/src/nsHTTPSOAPTransport.cpp:509
#10 0x42d54541 in nsXMLHttpRequest::NotifyEventListeners(nsIDOMEventListener*,
nsISupportsArray*, nsIDOMEvent*) (this=0xa127f38, aHandler=0x0,
    aListeners=0x8aed068, aEvent=0xa120ae8)
    at
/home/clfenwi/moz/mozilla/extensions/xmlextras/base/src/nsXMLHttpRequest.cpp:791
#11 0x42d56341 in nsXMLHttpRequest::RequestCompleted() (this=0xa127f38)
    at
/home/clfenwi/moz/mozilla/extensions/xmlextras/base/src/nsXMLHttpRequest.cpp:1341
#12 0x42d56133 in nsXMLHttpRequest::OnStopRequest(nsIRequest*, nsISupports*,
unsigned) (this=0xa127f38, request=0xa10ee00, ctxt=0x0, status=0)
    at
/home/clfenwi/moz/mozilla/extensions/xmlextras/base/src/nsXMLHttpRequest.cpp:1290
#13 0x41708e9e in nsStreamListenerTee::OnStopRequest(nsIRequest*, nsISupports*,
unsigned) (this=0x8d43778, request=0xa10ee00, context=0x0, status=0)
    at /home/clfenwi/moz/mozilla/netwerk/base/src/nsStreamListenerTee.cpp:65
#14 0x4178e557 in nsHttpChannel::OnStopRequest(nsIRequest*, nsISupports*,
unsigned) (this=0xa10ee00, request=0x9b841a0, ctxt=0x0, status=0)
    at /home/clfenwi/moz/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp:3616
#15 0x416e7354 in nsInputStreamPump::OnStateStop() (this=0x9b841a0)
    at /home/clfenwi/moz/mozilla/netwerk/base/src/nsInputStreamPump.cpp:505
#16 0x416e6db0 in nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (
    this=0x9b841a0, stream=0x8fd666c)
    at /home/clfenwi/moz/mozilla/netwerk/base/src/nsInputStreamPump.cpp:340
#17 0x40a18d6f in nsInputStreamReadyEvent::EventHandler(PLEvent*) (plevent=0x0)
    at /home/clfenwi/moz/mozilla/xpcom/io/nsStreamUtils.cpp:118
#18 0x40a358d9 in PL_HandleEvent (self=0xa1a4644)
    at /home/clfenwi/moz/mozilla/xpcom/threads/plevent.c:692
#19 0x40a357b2 in PL_ProcessPendingEvents (self=0x811efb0)
    at /home/clfenwi/moz/mozilla/xpcom/threads/plevent.c:627
#20 0x40a38168 in nsEventQueueImpl::ProcessPendingEvents() (this=0x810bb60)
    at /home/clfenwi/moz/mozilla/xpcom/threads/nsEventQueue.cpp:391
#21 0x41c1c646 in event_processor_callback (source=0x82a0888,
    condition=G_IO_IN, data=0xbfffe58e)
    at /home/clfenwi/moz/mozilla/widget/src/gtk2/nsAppShell.cpp:67
#22 0x40527def in g_io_unix_dispatch () from /opt/gnome/lib/libglib-2.0.so.0
#23 0x40505148 in g_main_dispatch () from /opt/gnome/lib/libglib-2.0.so.0
#24 0x405061a8 in g_main_context_dispatch ()
   from /opt/gnome/lib/libglib-2.0.so.0
#25 0x405065a8 in g_main_context_iterate ()
   from /opt/gnome/lib/libglib-2.0.so.0
#26 0x40506bf7 in g_main_loop_run () from /opt/gnome/lib/libglib-2.0.so.0
#27 0x402296ff in gtk_main () from /opt/gnome/lib/libgtk-x11-2.0.so.0
#28 0x41c1cbf0 in nsAppShell::Run() (this=0x81632c8)
    at /home/clfenwi/moz/mozilla/widget/src/gtk2/nsAppShell.cpp:142
#29 0x41b45b13 in nsAppShellService::Run() (this=0x8163260)
    at /home/clfenwi/moz/mozilla/xpfe/appshell/src/nsAppShellService.cpp:523
#30 0x08062a75 in main1 (argc=1, argv=0xbffff274, nativeApp=0x8137ca8)
    at /home/clfenwi/moz/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1302
#31 0x080633f8 in main (argc=1, argv=0xbffff274)
    at /home/clfenwi/moz/mozilla/xpfe/bootstrap/nsAppRunner.cpp:1779

Comment 4

[Doron Rosenberg (IBM)]

This crashes mozilla - bad bad thing.  This used to work with their old service,
so my guess is we are screwing up somewhere and crashing.

Comment 5

[timeless]

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/extensions/webservices/proxy/src/wspcallcontext.cpp&rev=1.10&cvsroot=/cvsroot&mark=319#300

312                    nsCOMPtr<nsISOAPPartBinding> partBinding =
313                      do_QueryInterface(binding, &rv);
314 vidur   1.1        if (NS_FAILED(rv)) {
315                      goto call_completion_end;
316                    }
317 jst     1.6  
318 vidur   1.1        PRUint16 location;
319                    partBinding->GetLocation(&location);

partbinding really shouldn't be null...

Comment 6

[Harshal Pradhan]

Attachment: Don't read beyond end of arrays

We shouldn't always expect to find as many SOAP blocks in the response as the
WSDL told us we would. Sometimes the server screws up and doesn't send us what
it promised (in this case, the server apparently is not sending us well formed
xml and expat barfed on us). And sometimes our SOAP implementation doesn't know
how to deal with that it sent us. In either case, we shouldn't read from memory
that hasn't been allocated.

Comment 7

[Harshal Pradhan]

Comment on attachment 149630 [details] [diff] [review]
Don't read beyond end of arrays

jst, r+sr ?

Comment 8

[Johnny Stenback (:jst)]

Comment on attachment 149630 [details] [diff] [review]
Don't read beyond end of arrays

r+sr=jst

And requesting 1.7 approval.

Comment 9

[Harshal Pradhan]

Thanks for the quick review. Checked in on trunk and 1.7 branch.

Comment 10

[Mike Connor [:mconnor]]

checked in on aviary branch