Menu
▾
▴
[Mingw-notify] [ mingw-Bugs-1105098 ] gnat, windows errorcodes wrong when tasking
|
From: SourceForge.net <no...@so...> - 2005-01-22 16:06:29
|
Bugs item #1105098, was opened at 2005-01-19 09:48 Message generated for change (Comment added) made by bnlbnl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1105098&group_id=2435 Category: gcc Group: None Status: Open Resolution: None Priority: 5 Submitted By: Björn (bnlbnl) Assigned to: Jerry van Dijk (jvandyk) Summary: gnat, windows errorcodes wrong when tasking Initial Comment: BUG REPORTS HAVE TO CONTAIN AT LEAST THE FOLLOWING INFORMATION IN ORDER TO BE USEFUL: the exact version of GCC, as shown by "gcc -v"; gcc -v Reading specs from C:/languages/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs Configured with: ../gcc/configure --with-gcc --with- gnu-ld --with-gnu-as --host=mingw32 -- target=mingw32 --prefix=/mingw --enable-threads -- disable-nls --enable- languages=c,c++,f77,ada,objc,java --disable-win32- registry --disable-shared --enable-sjlj-exceptions -- enable-libgcj --disable-java-awt --without-x --enable- java-gc=boehm --disable-libgcj-debug --enable- interpreter --enable-hash-synchronization --enable- libstdcxx-debug Thread model: win32 gcc version 3.4.2 (mingw-special) THE SYSTEM TYPE; Windows 2000 Professional, Windows 2000 Server, Windows 2003 THE OPTIONS WHEN GCC WAS CONFIGURED/BUILT; Binaries used from minGW containing MinGW version 3.2.0 contains the following list of packages: gcc-ada-3.4.2.tar.gz gcc-core-3.4.2.tar.gz gcc-g++-3.4.2.tar.gz gcc-g77-3.4.2.tar.gz gcc-java-3.4.2.tar.gz gcc-objc-3.4.2.tar.gz binutils-2.15.91-20040904-1 mingw-runtime-3.6 w32api-3.2 gdb-5.2.1-1 mingw32-make-3.80.0-3 mingw-utils-0.3.tar.gz But this bug also applies to the 'official' gnat 3.15p from ACT THE EXACT COMMAND LINE PASSED TO THE GCC PROGRAM TRIGGERING THE BUG (not just the flags passed to gnatmake, but gnatmake prints the parameters it passed to gcc) C:\Temp>gnatmake socket_connect.adb gcc -c socket_connect.adb socket_connect.adb:3:18: warning: "Gnat.Sockets.Thin" is an internal GNAT unit socket_connect.adb:3:18: warning: use of this unit is non-portable and version-d ependent gnatbind -x socket_connect.ali gnatlink socket_connect.ali A COLLECTION OF SOURCE FILES FOR REPRODUCING THE BUG, PREFERABLY A MINIMAL SET (SEE BELOW); with Text_Io; with Gnat.Sockets; with Gnat.Sockets.Thin; with Ada.Exceptions; procedure Socket_Connect is Socket : Gnat.Sockets.Socket_Type; Address : Gnat.Sockets.Sock_Addr_Type; Error : Integer := 0; -------------------------------------------------- task type Run_Once is entry Execute; end Run_Once; -------------------------------------------------- task body Run_Once is begin select accept Execute do text_io.put_line("Task running, Execute!"); end Execute; or terminate; end select; end Run_Once; -------------------------------------------------- begin declare TmpTask : Run_Once; begin TmpTask.Execute; end; text_io.put_line("Startup sockets"); Gnat.Sockets.Initialize; text_io.put_line("Get a socket"); Gnat.Sockets.Create_Socket (Socket); text_io.put_line("Try to connect!"); Address.Addr := Gnat.Sockets.Inet_Addr ("127.0.0.1"); Address.Port := 8000; Gnat.Sockets.Connect_Socket (Socket, Address); text_io.put_line("Connected!"); text_io.put_line("Close socket!"); Gnat.Sockets.Close_Socket (Socket); text_io.put_line("Shutdown sockets!"); Gnat.Sockets.Finalize; text_io.put_line("Done!"); exception when E: others => Text_IO.Put_Line(Ada.Exceptions.Exception_Name (E) & ": " & Ada.Exceptions.Exception_Message (E)); Error := Gnat.Sockets.Thin.Socket_Errno; Text_IO.Put_Line(Integer'Image(Error) & " - " ) ; --& -- Gnat.Sockets.Thin.Socket_Error_Message (Error)); Text_IO.Put_Line("Resolve_Exception" & " - " & Gnat.Sockets.Error_Type'Image (Gnat.Sockets.Resolve_Exception(E))); Gnat.Sockets.Finalize; end Socket_Connect; A DESCRIPTION OF THE EXPECTED BEHAVIOR; I'd like an output like this: C:\Temp>socket_connect Task running, Execute! Startup sockets Get a socket Try to connect! GNAT.SOCKETS.SOCKET_ERROR: [10061] Connection refused 10061 - Resolve_Exception - CONNECTION_REFUSED Note the second last line, printed by a call to Gnat.Sockets.Thin.Socket_Errno. I get the behavior when I comment out the task type. (well not the 'Task running, Execute' of course) A DESCRIPTION OF ACTUAL BEHAVIOR. C:\Temp>socket_connect Task running, Execute! Startup sockets Get a socket Try to connect! GNAT.SOCKETS.SOCKET_ERROR: [10061] Connection refused 0 - Resolve_Exception - CONNECTION_REFUSED Note the second last line, printed by a call to Gnat.Sockets.Thin.Socket_Errno. This time there's no error! This behavior occurs when any task at all is involved. If I write my own socket biding, and call WSAGetLastError (as Gnat.Sockets.Thin.Socket_Errno does) I still have this behavior. So I can recognize a socketerror, via the fact that c-socket function return -1 on error but NOT find the reason, unless I use Gnat.sockets, and mask the error out from the exception, which breaks socket code not written unsing Gnat.Sockets /Björn ---------------------------------------------------------------------- >Comment By: Björn (bnlbnl) Date: 2005-01-22 17:06 Message: Logged In: YES user_id=1200162 Jerry. I will not argue further, but I still consider an unpredictical behaviour of a program a bug. If I just declare the task, without declaring a task variable, thus not calling it, I still get the error. Clearly, the very presence of another task makes the errorcode break. As for mapping tasks to threads, I have this in chapter 12.1 of the Gnat reference manual of ACT's 3.15.p release with date: 2002/05/14 10:15:10 <quote> Whatever the underlying OS (VxWorks, UNIX, OS/2, Windows NT, etc.) the key point is that each Ada task is mapped on a thread in the underlying kernel. For example, in the case of VxWorks, one Ada task = one VxWorks task. In addition Ada task priorities map onto the underlying thread priorities. Mapping Ada tasks onto the underlying kernel threads has several advantages: 1 - The underlying scheduler is used to schedule the Ada tasks. This makes Ada tasks as efficient as kernel threads from a scheduling standpoint. 2 - Interaction with code written in C containing threads is eased since at the lowest level Ada tasks and C threads map onto the same underlying kernel concept. 3 - When an Ada task is blocked during I/O the remaining Ada tasks are able to proceed. 4 - On multi-processor systems Ada Tasks can execute in parallel. </quote> I've tested the code on Aix 5.2 with Gnat 3.16a (The ACT supported one) and on Mandrake Linux 10.1 with gcc : bnl@della2 test]$ gcc -v Reading specs from /usr/lib/gcc/i586-mandrake-linux-gnu/3.4.1/specs Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-clocale=gnu --disable-libunwind-exceptions --enable-languages=c,c++,ada,f77,objc,java --host=i586-mandrake-linux-gnu --with-system-zlib Thread model: posix gcc version 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk) and both behaved as expected. Clearly Ada is more portable than this ? Object Ada 7.2.2 also behaves as expected, on W2k and W2003. Not being used to arguing bug or not, I'm not sure this is the proper place for arguing. Perhaps comp.lang.ada is better? Besides, if this is NOT a bug, will this report count as a feature request? It would be nice to be able to write console based programs, and still trust the errorcodes, as I can do with other vendors compilers, even when tasks are involved. /Björn ---------------------------------------------------------------------- Comment By: Jerry van Dijk (jvandyk) Date: 2005-01-21 23:52 Message: Logged In: YES user_id=235403 From an Ada POV it is still not a bug since AFAIK neither the ARM nor the GNAT documentation gives you reason to belief that tasks will behave as if they are MS threads. Don't get me wrong, I understand what you are saying. It would be nice if it worked the way you want it to. But that is not sufficient to call it a bug. Maybe the ACT folks will think differently. ---------------------------------------------------------------------- Comment By: Björn (bnlbnl) Date: 2005-01-21 17:54 Message: Logged In: YES user_id=1200162 >This is not a bug as the package GNAT.Sockets.Thin is not >intended to be called by the user. Oh yes, it's a bug. Eventhough I should not call GNAT.Sockets.Thin.Socket_Errorno, I should be able to declare a function like function My_Error return Interfaces.C.Int; pragma Import (StdCall, My_Error,"WSAGetLastError"); which is exactly what GNAT.Sockets.Thin.Socket_Errorno does. Furthermore, I should be able to use it in a multitasking program as well, since WSAGetLastError is threadsafe according to Microsoft, see <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/wsagetlasterror_2.asp> Danny, I filed it to gcc at the same time I filed it here. Got ada/19526 as bug id /Björn ---------------------------------------------------------------------- Comment By: Jerry van Dijk (jvandyk) Date: 2005-01-21 11:44 Message: Logged In: YES user_id=235403 This is not a bug as the package GNAT.Sockets.Thin is not intended to be called by the user. Note the the compiler issues a warning for this: > warning: "Gnat.Sockets.Thin" is an internal GNAT unit > socket_connect.adb:3:18: warning: use of this unit is > non-portable and version-dependent Also the header of the package warns that: "This package provides a target dependent thin interface to the sockets layer for use by the GNAT.Sockets package socket.ads. This package should not be directly with'ed by an applications program." If a thinner binding than GNAT.Sockets is needed, the user will need to provide one himself. ---------------------------------------------------------------------- Comment By: Danny Smith (dannysmith) Date: 2005-01-21 09:51 Message: Logged In: YES user_id=11494 I am impressed with the detail of your bug report: It is excellent. I think I know where the problem is. Calls to the win32 api function TlsGetValue can reset the values retrieved by by GetLastError, so need to do something analogous to this from gthr-win32.h: static inline void * __gthread_getspecific (__gthread_key_t key) { DWORD lasterror; void *ptr; lasterror = GetLastError (); ptr = TlsGetValue (key); SetLastError (lasterror); return ptr; } It would be useful if you reported this bug to gcc Bugzilla database at: http://gcc.gnu.org/bugzilla/enter_bug.cgi so that Ada maintainers are aware of the problem. If you do not wish to do so, I can forward this bug report for you. I am also assigning to our Ada expert because I am not that familiar with gnat runtime lib, but I will stay in touch with this bug to see a resolution . Danny ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1105098&group_id=2435 |