[Mono-dev] 400 bad request when forwarding to xsp
I have XSP running on a machine behind a firewall/router. I have the XSP port forwarded. I have web pages and web services. When calling from the LAN, webservices work and web pages work, all being called with a web browser or .net code. When calling from the outside world web pages appear to work fine but some web services do not work. The web services fail with a 400 bad request WebException when calling from .net code and when calling from a web browser I just get Error: ConnectFailure. This only happens if coming from outside the LAN through the port forward. Also the web browser only fails to make the webservice call using POST as the method, if it uses GET as the method then the webservice works just fine. I have reproduced this on mono/xsp 1.1.10 and 1.1.13, I have yet to try it on 1.1.15 The error I get on code is: Exception: System.Net.WebException Message: The request failed with HTTP status 400: Bad Request. Source: System.Web.Services at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse (SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke (String methodName, Object[] parameters) I tried reading the response stream and got: Exception: System.Net.WebException Message: The request was aborted: The connection was closed unexpectedly. Source: System at System.Net.ConnectStream.BeginRead(Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state) at System.Net.ConnectStream.Read(Byte[] buffer, Int32 offset, Int32 size) at System.IO.Stream.ReadByte() Anyone else seen this? --Carlos ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem with Console.In.Peek() [hungs]
On Sat, 2006-05-06 at 00:59 +0200, Manfred Braun wrote: I am new on the road to make some things on my Unix box [which is NetBSD 3.0/i386] and I started using some simple console programs. My problem is, that the method Console.In.Peek() hungs, if no input stream is provided and I just execute the application. So if you do this: $ mono ct.exe Test. The program hangs. That's by design. :-) You are incorrect in your statement that no input stream is provided -- an input stream *is* provided, the console you're typing at. Furthermore, the documented return value of Peek() is this: The next character to be read, or -1 if no more characters are available or the stream does not support seeking. Since your program is reading standard input, and you haven't typed anything, there is no next character to read, more characters _may_ be available (end-of-stream hadn't been reached yet), and the underlying stdin stream _is_ seekable (at least in the forward direction, ignoring anything previously entered). Since none of those circumstances are met, the method hangs waiting for input from the console. So to fix the hang, provide some input, such as aRETURN or Ctrl+D (which ends the stream). Typing Ctrl+D will generate a -1 return value, as expected (because there was no data within the stream). So no wonder, that MS has the Console.In/Out implemented as TextReader and not as some stream Exposing Console.In/Console.Out as a Stream still wouldn't help you, for the precise reasons stated above -- the stream hasn't been closed yet (so no EndOfFile for you, which System.IO.Stream doesn't have anyway!), the stream is seekable, and no data is available. So you'd still end up blocking, waiting for some data to appear. and there is no way to make a connection between that, what the console is and a device, like the keyboard and or the screen/terminal. Define make a connection. System.Console.SetIn() allows you to set a new TextReader, and nothing stops you from opening /dev/hda1 into a Stream and constructing a StreamReader around that, e.g. System.Console.SetIn (new System.IO.StreamReader ( new System.IO.TextReader ( new System.IO.FileStream (/dev/hda1, System.IO.FileMode.Open, System.IO.FileAccess.Read) ) )); This probably won't work (/dev/hda1 is unlikely to have character data :-), but you get the point -- any device that has character data can become the source of System.Console.In. Granted, you can't tell what device System.Console.In is connected to, but you usually can't tell that on Unix anyway (except for isatty(3), which only tells you the file is a TTY, but it won't tell you what file/device you're actually reading). Does Mono implement the usual signals for processes so far? If you want to handle Unix signals, see Mono.Unix.Native.Syscall.signal(), within Mono.Posix.dll. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building Mono on Linux/Alpha
Hi, Exception support requires implementing: - the opcodes like throw, start_handler, endfinally - the functions in exceptions-ARCH.c - mono_arch_emit_exceptions (). As usual, the best documentation is the code of the other backends, but there is some documentation in mono/docs/exception-handling.txt. I suggest going throu the tests in exceptions.cs in the order they are in the file, and trying to implement the support needed by them. LMF handling can be done at a later stage since it is only needed by some later tests. Zoltan On 5/4/06, Sergey Tikhonov [EMAIL PROTECTED] wrote: Hello Zoltan, Either you should emit code to move from R0 to ins-dreg, or (better), modify your cpu-alpha.md file and the register allocator macros in mini-alpha.h to force the local register allocator to allways allocate the dreg of the call instruction to R0. This way the reg allocator will emit the move instruction if it is neccesary. Here is what a call instruction looks like in cpu-pentium.md: call: dest:a clob:c len:17 And the corresponding macro (only an example): #define MONO_ARCH_INST_FIXED_REG(desc) ((desc == 'a') ? X86_EAX : -1) Using different options triggered some interesting code I had to implement. My question is what is the difference between local and global registers? As I undertood the local registers could be used temporary in basic blocks, the global registers are used during optimizations. Can I define all my local registers as global ones? It seems that they couldn't mixed. Global registers are used during global register allocation. They should be distinct from the set of local registers. mono_arch_get_global_int_regs () returns the list of registers that should be used for global allocation. These registers are usually the 'callee-saved' registers defined by the platform ABI. The global register allocator will set cfg-used_int_regs if needed. I suggest returning an empty list from get_global_int_regs () until all tests are running, so you have a large set of regression tests which you can use to debug the inevitable problems which will arose when some variables are allocated to global registers. After some hacking I was able to run Hello world program. :) It still crashes somewhere at final stage of program rundown, but surely it did a lot before that. :) Now I have to implement hardest part - handling of exceptions. I need some hints here. :) - Of couse I am getting segfaults. For now I return -1 in mono_arch_find_jit_info. It seems to work in most cases - I am getting stack trace. But I guess there is not enough information to do correct unwinding and the VM segfaults again and goes to the loop of segfaults. If you could shed light here - it would be great. - Do I have to implement LMF handling to do correct unwinding? I don't have any LMF frames right now (it seems that I would have to save a lot of information in stack). - I don't have implemented any of throw, finally, call_handler - program exceptions. What are the requirements to implement it in general? Thank you, -- Sergey Tikhonov Solvo Ltd. Saint-Petersburg, Russia [EMAIL PROTECTED] ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] framework for system.web tests
Hello, I like this idea, definitely put it in svn. Maybe under the Test/mainsoft directory until we start using it for the individual unit tests? Why not adopt this to be part of the unit tests directly? And if this is not possible, we should add it as another check so we can use make run-test-local as a way of ensuring that we have not broken anything. Putting the tests in Test/mainsoft just means that we will not likely run those until someone does the work and we will just ignore them and not get the benefit of having them. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Please Help : Leak of wapi handles
Hello, http://bugzilla.ximian.com/show_bug.cgi?id=78241 but since the bug has been created nobody (from Novell) has written anything on it... I believe we tracked part of this problem; Can you try SVN Mono and report back? Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono Trace Leak patch
Hi, The attached patch fixes a leak in mono trace. mono_trace_cleanup was never called. Can someon merge it into svn. Joachim Ante mono_trace.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] framework for system.web tests
On Sat, 2006-05-06 at 13:45 -0400, Miguel de Icaza wrote: Hello, I like this idea, definitely put it in svn. Maybe under the Test/mainsoft directory until we start using it for the individual unit tests? Why not adopt this to be part of the unit tests directly? That's definitely the idea - the patch just didn't provide any changes to the existing unit tests. And if this is not possible, we should add it as another check so we can use make run-test-local as a way of ensuring that we have not broken anything. Putting the tests in Test/mainsoft just means that we will not likely run those until someone does the work and we will just ignore them and not get the benefit of having them. Right but there's no code here to actually run any new unit tests (or alter existing unit tests to make use of it). it's just framework code. I just figured getting it into svn someplace now (and later mv'ing it once we had patches to tests to started using it, or once we wrote new tests that depend on it) would be better than waiting until tests used it to get it in svn at all. Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Re: Please Help : Leak of wapi handles
Hi Miguel, http://bugzilla.ximian.com/show_bug.cgi?id=78241 but since the bug has been created nobody (from Novell) has written anything on it... I believe we tracked part of this problem; Can you try SVN Mono and report back? You probably mean this fix: http://lists.ximian.com/pipermail/mono-patches/2006-May/074236.html It doesn't fix the thread handles ref leaks I experienced. I was able to fix it by changing io-layer/threads.cs:GetCurrentThread to not ref the handle. I'm not sure about the side effects, still testing. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re: Please Help : Leak of wapi handles
Hello, You probably mean this fix: http://lists.ximian.com/pipermail/mono-patches/2006-May/074236.html It doesn't fix the thread handles ref leaks I experienced. I was able to fix it by changing io-layer/threads.cs:GetCurrentThread to not ref the handle. I'm not sure about the side effects, still testing. Ah, I felt that would help. Taking the ref inside GetCurrentThread in my opinion is an incorrect change. But I do not understand the ChangeLog entry nor why was that patch supposed to fix the other bug (or if the other bug listed on the SVN commit message is even the same fix). Gonzalo sent an email to Dick on Friday, we are waiting to see. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re: Please Help : Leak of wapi handles
At 06:41 PM 06/05/2006 -0400, Miguel de Icaza wrote: Hello, You probably mean this fix: http://lists.ximian.com/pipermail/mono-patches/2006-May/074236.html It doesn't fix the thread handles ref leaks I experienced. I was able to fix it by changing io-layer/threads.cs:GetCurrentThread to not ref the handle. I'm not sure about the side effects, still testing. Ah, I felt that would help. Taking the ref inside GetCurrentThread in my opinion is an incorrect change. But I do not understand the ChangeLog entry nor why was that patch supposed to fix the other bug (or if the other bug listed on the SVN commit message is even the same fix). As I understand it, the problem is that while certainly whenever a handle is created, it must represent a reference to the underlying object, the Windows GetCurrentThread() function doesn't actually create a handle. The comment block above the function in io-layer/threads.c reflects this (and it is, of course, documented in MSDN). If you create an actual handle but you don't increment the underlying object's reference count, then when the handle is closed, it'll decrement the reference count with no matching increment and the object will end up being released early, before the last handle is closed. What it boils down to is that it *is* correct behaviour for GetCurrentThread to not increase the reference count, but it is not correct behaviour for it to create a handle. Indeed, anyone following the MSDN documentation will not even bother to pass the handle GetCurrentThread returns into CloseHandle, so while in that situation, the object wouldn't end up being freed early as the reference count decrement in CloseHandle would never happen, a memory leak (albeit a small one) would occur (the size of whatever sits between a HANDLE and the underlying object). This leak is very likely what is causing the original poster's defect. The log message at the quoted URL also confuses me; it looks as though Gonzalo thinks io-layer's GetCurrentThread() is already matching Microsoft's pseudohandle behaviour. Certainly, though, the patch is correct if that code ever has to run on Windows (..and it'll also be correct if/when mono starts using pseudohandles too). :-) Jonathan Gilbert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
