|
From: dave t. <da...@co...> - 2003-11-26 10:01:09
|
Apologies for the direct email. I have a current need for debugging a memory leak in an application based on solaris. Back luck for me, that I only have access to some solaris compiled libraries (src is not available to me). I did try and download and install valgrind 2.0.0 but see configure confirm it's ix86 specific. Is a solaris version of valgrind ever likely ? -Dave Dave Tilley Staff Customer Applications Engineer CoWare Europe Ltd, United Kingdom |
|
From: Dirk M. <dm...@gm...> - 2003-11-27 09:09:47
|
On Wednesday 26 November 2003 12:01, dave tilley wrote: > Is a solaris version of valgrind ever likely ? Its on the todo,but if nobody is helping with it, its likely not going to happen. |
|
From: KJK::Hyperion <no...@li...> - 2003-11-29 01:02:16
|
At 10.19 27/11/2003, Nicholas Nethercote wrote: Apropos of this: >A Solaris port has been requested almost as frequently as a Windows port. I subscribed this mailing list precisely to ask about a Windows port, but gave up temporarily when I read on the website about Valgrind's non existent support for multi-threaded processes Assuming this isn't true anymore, I have a question for you: how does (or does) Valgrind cope with modifications on the current process performed by other processes? on Windows any process can modify any other process, given sufficient access to the target process object and related thread objects, and such modifications include allocating pages virtual memory, mapping pages of shared memory, writing ranges of memory, duplicating object handles, even altering the threads' contexts and LDTs. Such kind of interactions is a widely used form of inter-process communication (especially the exchange of object handles, which can also overwrite small areas of memory), and it makes the job of programs like Valgrind much harder without explicit support from the kernel. Also consider that kernel-mode code is free to write to any memory location, and some drivers may even create permanent kernel-mode threads in any process, so all of Valgrind's fancy memory checking and tracking can be quite pointless in several cases This is the only real difficulty on Windows, as system calls don't require to be run on any specific stack (in fact, the Win32 ExitThread function switches to a fixed stack allocated in the per-thread data segment before freeing the thread's real stack), all kernel-user transitions happen at well-known entry points (and this makes for easy hooking of exceptions, callbacks and APCs) and an APC (roughly equivalent to a signal), handled by a well-known function, is posted to every thread as soon as it's created, so hooking process and thread creation, and even running before any kind of initialization code, is a piece of cake >But a port would be difficult to a non-open source OS, because Valgrind >does lots of low-level OS stuff. Windows received a lot of attention from many skilled people, and Microsoft has let a lot of information to leak, over time. As an effect, we currently know a whole lot about its internals, including system calls (nearly all of them are officially undocumented), internal kernel features, routines and structures, and even the build environment used at the Microsoft labs. ReactOS (<http://www.reactos.com/>) is probably the greatest result achieved through this knowledge: it's an open source operating system aiming at (and slowly reaching) 100% binary compatibility with Windows. So this is not going to be the problem with Windows |
|
From: KJK::Hyperion <no...@li...> - 2003-11-30 15:10:44
|
At 13.10 29/11/2003, Nicholas Nethercote wrote: >>I subscribed this mailing list precisely to ask about a Windows port, but >>gave up temporarily when I read on the website about Valgrind's non >>existent support for multi-threaded processes >>Assuming this isn't true anymore, >Valgrind has supported multi-threaded processes for over a year now, maybe >even 18 months. this text in the technical overview is very misleading, then: >Threads >Doing a good job of thread support strikes me as almost a research-level >problem. The central issues are how to do fast cheap locking of the >VG_(primary_map) structure, whether or not accesses to the individual >secondary maps need locking, what race-condition issues result, and >whether the already-nasty mess that is the signal simulator needs further >hackery. > >I realise that threads are the most-frequently-requested feature, and I am >thinking about it all. If you have guru-level understanding of fast mutual >exclusion mechanisms and race conditions, I would be interested in hearing >from you. >>on Windows any process can modify any other process, given sufficient >>access to the target process object and related thread objects, and such >>modifications include allocating pages virtual memory, mapping pages of >>shared memory, writing ranges of memory, duplicating object handles, even >>altering the threads' contexts and LDTs. >Urgh... that sounds awful, like it would interact really badly with the >way Valgrind works. well, not that this kind of things happens normally. I think most inter-process memory writes happen either in a controlled way through the RPC system calls, and they're easily trackable, or through shared memory, something Valgrind wouldn't have much control on anyway. But you confirmed one of my fears. I guess I can lower the priority of a Valgrind port on my to-do list On a lighter note, Windows is very liberal about features and practices that would make any purist OS developer crazy. System calls, for example, use pointers passed by user-mode programs directly (after checking that the whole range is contained in user-mode memory, of course), with no explicit checking: access violations (segmentation faults) are handled in a manner similar to C++ exceptions, by unwinding the stack frames until the exception handler and setting the return value to the exception code. This isn't an implementation accident, but an explicit design feature: error codes and exception codes even share the same namespace (e.g. in UNIX you have EFAULT and SIGSEGV, while in Windows NT STATUS_ACCESS_VIOLATION covers both). You may also be surprised and outraged to discover that "statically linked" programs are impossible: as soon as a process is created, a special DLL (ntdll.dll) is injected into it, that contains the executable loader, the system call thunks and some runtime libraries (like the heap manager). Another cause of surprise and frustration is the area of memory shared between the kernel and every user-mode process: not a bad idea in itself (it lets you access the internal tick counter directly, discover the kernel version, and more), if only it wasn't loaded at a fixed address. In general, kernel-user interactions are often unorthodox and pretty extreme. The windowing system, for example, having been ported from a shared-memory system (think Windows 3.1), lets any client access its internal data structures (read-only, of course) - GDI handles, if any of you is familiar with them, aren't handles at all, but indexes in a huge array of GDI objects; same for window handles. Not to take up precious kernel virtual memory, the windowing system maps its shared data in write mode in a special process, and switches to its virtual address space whenever it needs to make any modification. And I think I already mentioned the kernel-mode threads you're free to create in any process >>This is the only real difficulty on Windows >Er, I think that might be understating things a bit. For example, I >imagine it would be much easier to port to a *nix OS than to Windows. hm, I don't know. How does Valgrind's memory checking work? does it keep a cache of the memory status somewhere? and the real memory of the process is kept in synch with the emulated memory? [ReactOS] >I had a look at that site. AFAICT, they started in 1997, and can now run >a few programs on NT 4.0. we can run a few Windows NT 4 *drivers*, please :-) >Sure, it is possible to find out about Windows internals, but a port to an >open-source OS would be *much* easier. I think that's not the major problem here. Let's say I am providing a precedent you can point people at (is this mailing list archived somewhere?) |
|
From: Nicholas N. <nj...@ca...> - 2003-12-01 13:03:43
|
On Sun, 30 Nov 2003, KJK::Hyperion wrote: > >I imagine it would be much easier to port to a *nix OS than to Windows. > > hm, I don't know. How does Valgrind's memory checking work? does it keep a > cache of the memory status somewhere? and the real memory of the process is > kept in synch with the emulated memory? Real memory is shadowed by shadow memory, which records accessibility for every byte, and validity for every bit. Some other tools (Valgrind is a suite of tools, the memory checker is only one) have similar shadow memory, some don't shadow memory at all. > >Sure, it is possible to find out about Windows internals, but a port to an > >open-source OS would be *much* easier. > > I think that's not the major problem here. What do you think is the major problem? > Let's say I am providing a precedent you can point people at (is this > mailing list archived somewhere?) The list is archived at SF.net, but unfortunately I don't think it's searchable, which is pretty lame. N |
|
From: Nicholas N. <nj...@ca...> - 2003-11-27 09:19:49
|
On Thu, 27 Nov 2003, Dirk Mueller wrote: > > Is a solaris version of valgrind ever likely ? > > Its on the todo,but if nobody is helping with it, its likely not going to > happen. Note that this is on the very-speculative-and-would-be-a-lot-of-work part of the todo list :) A Solaris port has been requested almost as frequently as a Windows port. But a port would be difficult to a non-open source OS, because Valgrind does lots of low-level OS stuff. A BSD port (FreeBSD is easily the most asked-for) would be a much easier first OS port. Also, I suspect we wouldn't get full value out of a Solaris port without also doing a SPARC architecture port. N |
|
From: Nicholas N. <nj...@ca...> - 2003-11-29 12:10:41
|
On Fri, 28 Nov 2003, KJK::Hyperion wrote: > I subscribed this mailing list precisely to ask about a Windows port, but > gave up temporarily when I read on the website about Valgrind's non > existent support for multi-threaded processes > Assuming this isn't true anymore, Valgrind has supported multi-threaded processes for over a year now, maybe even 18 months. IIRC, it has supported multi-threaded processes for much longer than the mailing lists have been in existence. > I have a question for you: how does (or does) Valgrind cope with > modifications on the current process performed by other processes? Not well; there's very, very limited support. > on Windows any process can modify any other process, given sufficient > access to the target process object and related thread objects, and such > modifications include allocating pages virtual memory, mapping pages of > shared memory, writing ranges of memory, duplicating object handles, > even altering the threads' contexts and LDTs. Urgh... that sounds awful, like it would interact really badly with the way Valgrind works. > This is the only real difficulty on Windows Er, I think that might be understating things a bit. For example, I imagine it would be much easier to port to a *nix OS than to Windows. > Windows received a lot of attention from many skilled people, and Microsoft > has let a lot of information to leak, over time. As an effect, we currently > know a whole lot about its internals, including system calls (nearly all of > them are officially undocumented), internal kernel features, routines and > structures, and even the build environment used at the Microsoft labs. > ReactOS (<http://www.reactos.com/>) is probably the greatest result > achieved through this knowledge: it's an open source operating system > aiming at (and slowly reaching) 100% binary compatibility with Windows. So > this is not going to be the problem with Windows I had a look at that site. AFAICT, they started in 1997, and can now run a few programs on NT 4.0. Sure, it is possible to find out about Windows internals, but a port to an open-source OS would be *much* easier. N |