lstat symbolic link size
lstat returns an incorrect symbolic link size, with size 11 bytes too large.
This causes mkcramfs to fail.
CYGWIN variable is set to nowinsymlinks. Set to winsymlinks, the size is about 80
bytes too large.
This is for a cygwin snapshot from September.
This program generates the error for me. Create a symbolic link, e.g.
ln -s -f x x
compile program. e.g. gcc chklnk.c -o chklnk
test. e.g. ./chklnk x
Source for chklnk.c
---
#include
#include
#include
int main(int argc, char ** argv)
{
int r;
struct stat st;
if(argc != 2)exit(-1);
r = lstat(argv[1],&st);
if(r != 0){ printf("lstat fails\n");exit(-1);}
if(!S_ISLNK(st.st_mode)){printf("Not a symbolic link\n");exit(0);}
printf("Size %d\n",(int)(st.st_size));
return 0;
}
--
__
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.
Powered by Outblaze
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
readlink null termination problem
I was having a problem with mkcramfs on cygwin creating symbolic links for the compressed linux filesystem. mkcramfs uses malloc to allocate a buffer that it sends to the readlink function in cygwin path.cc That function uses memcpy to do a copy of the link into a buffer. Neither mkcramfs or readlink is null-terminating the string representing the link. Probably both are at fault. I have fixed my problem by zeroing the buffer in mkcramfs before calling readlink, but it would probably be beneficial if readlink terminates the returned string, if there is room. -- __ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Is multithreaded profiling on cygwin possible
Brian Ford wrote: >On Fri, 17 Oct 2003, peter garrone wrote: > > >> I have dropped the dll import library concept. >> >Probably good. Although, it would still be neat to figure out a way to >trace back to the application "leaf" functions. I guess that will be an >"exercise" for later. Unfortunately I dont have any problems that this approach would address. I am keeping a copy of my work so far, and would send it to anyone, but I have no current plans to continue with it. >> My current approach is to keep track of the time accumulated >> by each thread, and when it has exceeded the amount represented >> by a profiling period, assign the tick to the current PC, >> and subtract that amount of time from the running total for the >> thread. So it always adds up, anyway. >> >I was going to suggest this when we were talking about partial ticks, but >I was worried about charging time to the wrong PC. Looking back, this >still fits in fine with the PC sampling "philosophy". Yes. It does get a bit philosophical. The program being profiled must be regarded as a random process in itself, so adding an RNG only confuses the issue. > >> I still have it so that each thread that is to be profiled calls >> moncontrol(1). Also, an application compiled and linked without >> -pg could always use the "profil" call in a similar way. >> Each thread would call profil with identical parameters. >> >It should be simple to add an "all threads" mode later if we want, so this >is fine. Does the main thread still call moncontrol(1) when compiled with >-pg? I would think this would be required. Yes. It links in a special crt program that calls moncontrol(1). On linux, it is necessary to call getitimer/setitimer for each thread as discussed previously, and with this code on cygwin moncontrol(1). But this allows a lot of flexibility. > >> To do the DLL's, I have added a linked list of profiling ranges >> to profil.c. These ranges are specified using an environment >> variable. The ranges may be DLL specific, or general memory ranges. >> There is a separate data file output upon program termination >> for each range, in addition to gmon.out. >> >The linked list sounds reasonable. I guess if there were too many >threads, something less linear would be better. Does anyone have a >suggestion about how to find these address ranges automatically (at least >for non dynamically loaded DLLs)? > >I assume the gmon.out file contains just the original program proper >memory range? Yes, from "text" to "etext", the static linked range. This is as per the current gmon.c file, which I am not proposing to change. If call counts were required, it is usually possible to link a cygwin dll function statically, and that would produce the call counts. > >I really wish we could get someone on the binutils list interested in >helping to extend the gmon.out file format to contain multiple hashes. We >would still need a method to map the ranges to the DLLs. Determining the >DLLs should be easy unless they were dynamically loaded. You really >should send at least a ping over there, but you're doing all the work, so >I'll shut up now. As it pans out, it doesnt seem so necessary to me, because gprof profiles the un-stripped DLL's as they are. gprof does one thing well, profiling a BFD, which is sort of in line with the UNIX philosophy. All the profiling data exist as separate files for the various profiling ranges. This way solves my current profiling problems and gives me fine control. Why profile every DLL when you may only be interested in one? But it is absolutely essential to me to be able to profile selected memory ranges. > >> If a dll has not been stripped, gprof will use the data file >> and the dll to output a flat profile, but without call counts though. >> (At least this works with cygwin1.dll) >> >That sounds like it would be *really* usefull to cygwin developers! This >concept was discussed before in the references I gave you, but never >pushed this far. I must say that it was unforeseen by myself, and very easy, accidental almost. I had to save the profiling data for raw address ranges in some format, gmon.out being the logical one. That was all the work necessary. I wondered if gprof would work with that data, and it did. I hope this is standard for gprof, as in it reads any BFD with symbolic information, and not some kludge. I am not expert enough to know. > >> I have written a simple utility to summarise the information >> in these data files, giving flat addresses and CPU usage. >> >This sounds like a useful inclusion. Again, it would be more functional >if we could feed al
Re: Is multithreaded profiling on cygwin possible?
>Even if no one else comments, I really appreciate all this work you're >doing! Also, thanks for continuing to send me the updated patches. I >wish I had more time to look over them in detail right now. I'll try and >do that soon. I assume it is ok to give an open invitation for anyone >else who would like to give the a whirl? > >BTW, if you are interested in contributing this, please take a look at the >"Before you get started" section of http://cygwin.com/contrib.html since >the assignment process can take some time. > >Again, great work from my point of view! > >-- >Brian Ford >Senior Realtime Software Engineer >VITAL - Visual Simulation Systems >FlightSafety International >Phone: 314-551-8460 >Fax: 314-551-8444 > Thanks Brian. This message, I believe, gives the code upon which Brian's endorsement is based. Regarding the IP issues, there is no problem with my posting the code to the group, or with anyone using it, from my employers point of view. No warranty is implied etc. I have forwarded the small document that our legal people need to sign. Until then I would imagine that the code cannot be part of cygwin. This message contains the code for two files, profil.c, and gmraw.c. To use this code, replace winsup/cygwin/profil.c with the file profil.c here. Recompile cygwin. Either update the DLL, or directly link in the profil.o object file. - Compile and link with -pg. - If using multi-threaded code, each new thread needs to call "moncontrol(1)" upon creation. The main thread calls it automatically. - To profile DLL's, and general memory ranges, set the environment variable PROFILE_RANGE. This variable should consist of one or more colon separated entries. Each entry consists of a name, followed by optional comma separated fields representing the scale, offset, and size, in hex. It the name is the name of a DLL, then the entry is a DLL entry, else a general memory range. The scale field determines the profiling resolution. Divide 0x1 by the scale value to give the profiling resolution in bytes. For a DLL, the default scale is 1 giving a resolution of 1 byte. For a memory range, the default scale is such as to give 256 incrementing counters, or a scale of 1 if the range is too great for that. If the name is the name of a DLL, then the offset is with respect to the loaded DLL, otherwise it is a fixed address. The default offset value is zero. The size field defines the size of the address range to be profiled. If the range covers a DLL, then the default value is the size of the DLL less the offset. If the range is a general memory range, the default size is 0x8000. I use the following to profile all the DLL's my application links to, the entire memory range from 0 to 0x8000 (called "general"), and a small area where my application is spending a lot of CPU (called "busy"). The list of DLL's was obtained using cygcheck. export PROFILE_RANGE='general:busy,1,7ffe,1:cygX11-6.dll:cygcygipc-2.dll:cygwin1.dll:KERNEL32.dll:ntdll.dll:GDI32.dll:USER32.dll:ADVAPI32.dll:RPCRT4.dll:GLU32.DLL:msvcrt.dll:OPENGL32.dll:DDRAW.dll:DCIMAN32.dll:glut32.dll:WINMM.dll' Alternatively, the following command causes only the cygwin dll to be profiled. export PROFILE_RANGE='cygwin1.dll' - Execute your program. Upon program termination, besides gmon.out, a file in gmon.out format will be output for each range, with ".gmonout" appended to the name of each range, cygwin1.dll.gmonout etc. To profile the cygwin dll, provided you are using an unstripped dll, the command gprof /bin/cygwin1.dll cygwin1.dll.gmonout produces a flat profile. To see a memory range, or for dlls with no symbolic information, a utility called gmraw is provided. Compile this with "gcc gmraw.c -o gmraw". The command "gmraw -f general.gmonout" for example provides information about that particular range. - WRT the interface. Calling moncontrol(0) at any point should terminate the profiling thread, and profiling of the memory ranges, but the data should still be saved upon program termination. It should be possible to use the "profil" function provided "-pg" compilation/linkage option is not used. Each thread should call "profil" with identical parameters. I have not tested this much. - File profil.c - /* profil.c -- win32 profil.c equivalent Copyright 1998, 1999, 2000, 2001 Red Hat, Inc. This file is part of Cygwin. This software is a copyrighted work licensed under the terms of the Cygwin license. Please consult the file "CYGWIN_LICENSE" for details. */ #include #include #include #include #include #include #include #include #include #include #include #include #define SLEEPTIME (1000 / PROF_HZ) #define MAXTHREADS 256 /** * This is a per-threa
gdb startup error
Hi, Whenever I type gdb from the bash command line, a little window immediately pops up Window title: "gdb.exe Application Error" and text is: "The application failed to initialize properly(0xc07b)" The gdb executable is Sep 20 12:45 2365952 bytes. This also happens for the "insight" command. But everything else is OK. I believe gdb was working until I recently upgraded my system. cygcheck says I have gdb package version 20030919-1 and that it is OK. To list my own debugging attempts, My search of the net says that the only possible cause of c07b, standing for STATUS_INVALID_IMAGE_FORMAT, is a failure of the function _CorValidateImage, for xp systems. I am running xp. Also a DLL stuffup could be the cause. Any help appreciated. -- __ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Is multithreaded profiling on cygwin possible?
Hi Brian Thanks very much for your comments. I think I have changed my approach so that it is broadly similar to your suggestions, but may differ in some details. I have dropped the RNG. I dont think it is necessary or warranted. I have dropped the dll import library concept. I would agree that Corinna's suggestion about WaitForSingleObject is probably better, though I havent yet done it that way. My current approach is to keep track of the time accumulated by each thread, and when it has exceeded the amount represented by a profiling period, assign the tick to the current PC, and subtract that amount of time from the running total for the thread. So it always adds up, anyway. I still have it so that each thread that is to be profiled calls moncontrol(1). Also, an application compiled and linked without -pg could always use the "profil" call in a similar way. Each thread would call profil with identical parameters. To do the DLL's, I have added a linked list of profiling ranges to profil.c. These ranges are specified using an environment variable. The ranges may be DLL specific, or general memory ranges. There is a separate data file output upon program termination for each range, in addition to gmon.out. If a dll has not been stripped, gprof will use the data file and the dll to output a flat profile, but without call counts though. (At least this works with cygwin1.dll) I have written a simple utility to summarise the information in these data files, giving flat addresses and CPU usage. Peter Garrone -- __ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Is multithreaded profiling on cygwin possible?
Brian Ford wrote: > >On Tue, 14 Oct 2003, peter garrone wrote: > >> A list of active threads is maintained. A thread calling moncontrol(1) gets >> put in the list. When a call to SuspendThread fails, the thread is assumed >> to be defunct and taken off the list. >> >Seems reasonable. > >I guess I was originally thinking "just profile all threads all the >time", but I guess you method is more flexable. That could >probably be an option somehow after you polish this up. There is no other way to detect a dead thread. Nothing like "atexit" or anything I could find anyway in the win32 api, of which my experience is limited, and ordinary. > >> One of the fields in the thread is a counter corresponding to the sum of cpu >> returned by GetThreadTimes. This function has fields corresponding to >> kernel cpu and user cpu. The amount of time consumed by every thread is >> saved. >> >> Generally only one thread will have consumed CPU. However to be general, >> and in case the profiling thread is inadvertently delayed, all threads are >> considered. >> >> There is a partial tick problem. Suppose that a thread has consumed say >> 155% of the cpu time corresponding to a tick. I would assign one tick >> and use a local random number generator to assign an extra tick on >> average 55% of the time. >> >I'm getting lost here. > >What is your tick definition? A sampling interval? Yes. The amount of CPU usage corresponging to a loop of the profiling sampler. The amount represented by incrementing the sample data by one. The amount of time represented by (1.0/PROF_HZ) > >How can a thread ever consume more that 100%? I can see how two or more >threads might on a multi CPU system. The profiling thread calls Sleep. That function is guaranteed to sleep for at least its argument. It can always sleep longer. So the actual profiling interval could be longer than the nominal profiling interval. In the meantime, a thread could have consumed more than one interval worth of cpu. > >I'm lost in the random number generator application too. > 1) The rng algorithm itself Its a linear congruential rng algorithm. Given a 31 bit seed, do a 64 bit multiply by 69069, add 1, and mask off the lower 31 bits. I dont think the application calls for anything special. If it bothers you, call rand(); I dont have references for this, but I'm preety sure it has been academically described and extensively tested. As an RNG, it does have severe limitations but it is very fast. 2) Why use one? What else do you do if only a fraction of a tick is used. If a thread has consumed say 70% of a complete ticks worth of cpu, then roll the dice and 70% of the time assign a tick. I dont think I can explain it better. It all averages out in the end, and its basically an estimate anyway. >> I tried getting the program counter for all threads, but this was found >> not to work very well, consuming excessive cpu, on average 50 milliseconds. >> >I thought there might be an overhead issue. Definitely. This was causing the scheduler to assign very long profile thread sleeptimes, much longer than nominal, and is the reason for all the probabilistic stuff. That scheduler is a bit sus. >Please do (come back with your results, that is). I'm definately >interested. > Concerning the DLL import function profile assignment solution, I can get it to work, but only for toy situations unfortunately. If I create a simple test DLL, then it apparently works OK, giving about 70 nanoseconds per DLL function call, 7 seconds for 100 million, compared with about 20 nanoseconds for a simple unoptimised profiled function call, and some nice looking gprof output indeed. However when I try things like the cygwin dll or kernel32, I just get a segmentation violation on startup. I think there are some issues with the import library format which I dont understand. I have changed the little bit of code found in dlltool.c that goes in each import library function to cause a call to the profiler code, which is always at a fixed address since I cant get ld to accept an extra relocation. Also I might have some assembler issues. I am currently trashing eax and edx in the profiler call, which C functions appear to do. My cygwin installation is behaving rather oddly at the moment so it could be something to do with that. I have a snapshot, and I have to have my own version of bash, compiled with that snapshot unfortunately. gdb always has an application initialization failure on startup. Setup hangs at the last. I think I'll try a new snapshot. Any suggestions on this, by anyone at all, would be greatly appreciated. Cheers, Peter -- __ Check out the latest SMS services @ http://www.linuxmail.or
Re: Is multithreaded profiling on cygwin possible?
- Original Message - From: Brian Ford <[EMAIL PROTECTED]> Date: Mon, 13 Oct 2003 14:36:34 -0500 (CDT) To: peter garrone <[EMAIL PROTECTED]> Subject: Re: Is multithreaded profiling on cygwin possible? > On Mon, 13 Oct 2003, peter garrone wrote: > > > > Sounds good, although I'm not quite sure I understand the implementation. > What you really need to know is what thread was running just before the > sampling thread so that it can sample the correct thread's PC. How are > you using GetThreadTimes for this? A list of active threads is maintained. A thread calling moncontrol(1) gets put in the list. When a call to SuspendThread fails, the thread is assumed to be defunct and taken off the list. One of the fields in the thread is a counter corresponding to the sum of cpu returned by GetThreadTimes. This function has fields corresponding to kernel cpu and user cpu. The amount of time consumed by every thread is saved. Generally only one thread will have consumed CPU. However to be general, and in case the profiling thread is inadvertently delayed, all threads are considered. There is a partial tick problem. Suppose that a thread has consumed say 155% of the cpu time corresponding to a tick. I would assign one tick and use a local random number generator to assign an extra tick on average 55% of the time. I tried getting the program counter for all threads, but this was found not to work very well, consuming excessive cpu, on average 50 milliseconds. All the other calls were of the order of 1 microsecond. However getting the program counter only for any thread that used cpu according to GetThreadTimes appeared to take about 50 microseconds. Generally of course only one thread will have used CPU. The function GetThreadContext is used to obtain the PC. > > I tried using a backtrace method to map the sampling time onto > DLL leaf functions (the import stubs) once, but it did not seem possible > to perfect. Also, that is not always what you want. I would be interested if you would expand on this. Do you mean looking at the stack to find the calling function? > But, if you want this to be usefull for the community at large, attacking > the two points in the previous email directly would probably be more > useful. ie. Figure out a way to store the samples using a > non-contiguous address space model, and modify gprof to load the symbol > tables for the dependent DLLs (gdb does this to some extent). Note that > UNIX shared libraries have similar issues. You may want to consult with > [EMAIL PROTECTED] for a general solution since they "own" gprof. > I am thinking of implementing a separate profil call so that it can be used simultaneously with -pg compilation and linking. Also a "profile-dll" call so that profiling of the space occupied by a dll would occur. My problem with profiling the entire dll address space is 1) The necessity of recompiling dll's so that mapping and call counting is implemented 2) The difficulty of doing anything with propriety dll's 3) The size and sparsity of the resulting gmon.out data file. So I thought I would try attacking the problem using the import libraries. Perhaps it is a silly idea, but if it could be made to work it avoids these problems. If I can get it to work, I'll be back. Thanks -- __ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Is multithreaded profiling on cygwin possible?
Brian Ford wrote: >2.) Paraphrasing, the UNIX profil call (that gprof.c is currently using), >has a contiguous flat address space model. It hashes address samples over >that space into a buffer. The starting and ending address are >automatically pulled from the executable and are in its address space. >DLLs are mapped outside this space non-contiguously. > >4.) Paraphrasing, gprof doesn't know how to find and read the symbol >tables from DLLs linked into the executable. I'm not even sure if the >addresses are deterministic. > As you have suggested, I have tried setting up a list of threads in profil.c, calling SuspendThread, GetThreadTimes, to get timing information for all threads, and to create a reasonably accurate profile for non-dll user space using gprof. My plan now is to create new dll import libraries so that when these dll functions are called, a flag is set in the thread structure list, and the profiling thread assigns cpu ticks against the statically linked small import functions, so that hopefully gprof will pick it up and assign some sort of cpu usage and call frequency count to all the functions in the import libraries. If you can see any obvious pitfalls with this approach, I would be grateful. -- __ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Is multithreaded profiling on cygwin possible?
Sorry for the delay, or the repeat information, my original reply is lost. Brian Ford wrote: >peter garrone wrote: > >>If I profile my multi-threaded application, it appears that only the main >>thread is profiled. >> >Currently, yes. Actually, I think I was only partially correct. Time for the main thread is accumulated, but function calls are counted for all threads. This creates misleading data. > >You can, however, profile other threads one at a time if you use >the gprof API's manually, called from the thread you want to profile. I >have done this, but it has been too long for me to give you specific >instructions. Have a look at profile.c, profile.[ch], gmon.[ch] in the >cygwin sources to see how its done. Thanks very much, this advice is a great start. I didnt see any way in the mcount function (winsup/cygwin/mcount.c) to specify a particular thread. I did see the possibility of calling moncontrol(1) to enable time accumulation for a particular thread, and searching dejanews, noticed that this is a recognised approach to multithreaded profiling. > >PTC >While you're there, it should be fairly trivial to create a patch that >at least loops through all Cygwin created pthreads in the sampler. I >don't know if that kind of flat profile is what you wanted, though. Sometimes per-thread profiling is useful, but a flat profile is what I want for now. Not so much for optimisation, but porting. If a thread is taking x% cpu on system 1 and y% cpu on system 2, then per-thread profiling is useful. If the whole application is running much too slow, then the flat profile is useful. I havent figured out how to get per-thread cpu on cygwin yet anyway. You commented that dll code is difficult to profile. Would you kindly send me a few references to this, or keyword sets, my searching is blank. I am aware of the "profiling cygwin" information, and assume you mean extra to this. >>On linux, it is possible to save and set the virtual timer upon creation >>of each thread, and thereby get a decent profile. >>However the virtual timer is unavailable on cygwin, and I would imagine >>that this approach is incorrect, due to differing thread models. >> >I've never profiled on Linux and I don't know anything about the virtual >timer you are refering to. On Solaris, I get a nice flat profile of all >threads combined, like the implimentation I suggested above. The same >shared library concerns exist there, but Solaris is good about providing >static profile enabled libs. Sorry, I was incorrect. I meant by saving the profiling timer ITIMER_PROF before thread creation and resetting after, in the thread, cpu profiling was possible. Refer <http://sam.zoy.org/writings/programming/gprof.html> > >Let me know if you want to discuss patch ideas. I used to have a few, but >no priority time to work on them. :( I am afraid that this email is the sum of my current knowledge about cygwin profiling. But if I find out anything else, I will post it. -- __ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Is multithreaded profiling on cygwin possible?
Firstly, apologies for repeated postings to the gmane cygwin newsgroup, I thought they were bounced. If I profile my multi-threaded application, it appears that only the main thread is profiled. On linux, it is possible to save and set the virtual timer upon creation of each thread, and thereby get a decent profile. However the virtual timer is unavailable on cygwin, and I would imagine that this approach is incorrect, due to differing thread models. -- __ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: munmap bug test program
>On Tue, Sep 30, 2003 at 10:06:11AM +0800, peter garrone wrote: >> This test program highlights the recent munmap problem addressed by Corinna. >> It works with the updated mmap, and with linux, fails on cygwin with the prior mmap. > >What "updated" mmap are you talking about, your's or the one in CVS? >Corinna The one in CVS, I believe I tested it with the one I submitted as well. -- __ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: munmap bug test program
I said this test program works with both my own and corinna's fix, but in fact I have only actually tested it with corinna's fix, since I discarded my own. -- __ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re:munmap bug test program
>On Tue, Sep 30, 2003 at 10:06:11AM +0800, peter garrone wrote: >> This test program highlights the recent munmap problem addressed by Corinna. >> It works with the updated mmap, and with linux, fails on cygwin with the prior mmap. > >What "updated" mmap are you talking about, your's or the one in CVS? > >Corinna It works with both. I am using your fix, ie the one in CVS. -- __ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
munmap bug test program
This test program highlights the recent munmap problem addressed by Corinna.
It works with the updated mmap, and with linux, fails on cygwin with the prior mmap.
/**
* mmap test.
* mmaps two chunks of adjacent memory, then munmaps one and a half,
* then sees if the remainder is still useable.
*/
#include
#include
#include
#include
#include
#include
#include
#ifndef _POSIX_MAPPED_FILES
#warning Testing mmap/munmap, but _POSIX_MAPPED_FILES not defined.
#endif
#define CHUNKSIZE 0x1
#undef Dim
#define Dim(x) ((int)(sizeof(x)/sizeof(x[0])))
void * mapping1,*mapping2;
char buff[CHUNKSIZE*4];
int main()
{
int fd;
int r;
int temp_open_flags;
char name[] = "test_cygwin_munmapXX";
fd = mkstemp(name);
assert(fd != -1);
temp_open_flags = fcntl(fd, F_GETFL);
assert(temp_open_flags != -1);
assert((temp_open_flags & O_RDWR) == O_RDWR);
/* Have to write to the file for mapping to work. */
r = write(fd, buff, sizeof(buff));
assert(r == sizeof(buff));
mapping1 = mmap(0, 2*CHUNKSIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
assert(mapping1 != MAP_FAILED);
mapping2 = mmap(mapping1 + 2*CHUNKSIZE, 2*CHUNKSIZE,
PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_FIXED, fd,
2*CHUNKSIZE);
if(mapping2 == MAP_FAILED)
{
printf("OS wont do contiguous memory file mappings. Cant do test. Try
changing CHUNKSIZE\n");
munmap(mapping1, 2*CHUNKSIZE);
close(fd);
unlink(name);
exit(0);
}
printf("mappings: %x %x\n",mapping1,mapping2);
/* Unmap from middle of first chunk to end of second chunk. */
r = munmap(mapping1 + CHUNKSIZE, 3*CHUNKSIZE);
assert(r == 0);
/* now try setting the first half of the first chunk */
memset(mapping1, 0, CHUNKSIZE);
close(fd);
/* Unmap the last bit, so hopefully the unlink of the temporary file will
work. */
r = munmap(mapping1, CHUNKSIZE);
assert(r == 0);
r = unlink(name);
assert(r == 0);
return 0;
}
--
__
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
possible munmap bug
Hi,
This was causing my build of gcc to fail.
File winsup/cygwin/mmap.cc version 1.86 (and earlier) function munmap
when unmapping a 64K record, passes the wrong parameters to fhandler_base::munmap,
passing the function parameter address/length instead of a block local version.
This patch explains it all.
diff -r -p -U 5 cygwin-snapshot-20030924-1/winsup/cygwin/mmap.cc
new_cygwin/winsup/cygwin/mmap.cc
--- cygwin-snapshot-20030924-1/winsup/cygwin/mmap.cc2003-09-25 10:40:33.0
+1000
+++ new_cygwin/winsup/cygwin/mmap.cc2003-09-26 11:34:29.984375000 +1000
@@ -679,11 +679,11 @@ munmap (void *addr, size_t len)
mmap_record *rec = map_list->get_record (record_idx);
if (rec->unmap_pages (u_addr, u_len))
{
/* The whole record has been unmapped, so... */
fhandler_base *fh = rec->alloc_fh ();
- fh->munmap (rec->get_handle (), (caddr_t)addr, len);
+ fh->munmap (rec->get_handle (), (caddr_t)u_addr, u_len);
rec->free_fh (fh);
/* ...delete the record. */
if (map_list->del_record (record_idx--))
{
--
__
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: feature requests for setup
- Original Message - From: Igor Pechtchanski <[EMAIL PROTECTED]> Date: Tue, 23 Sep 2003 23:56:04 -0400 (EDT) To: peter garrone <[EMAIL PROTECTED]> Subject: Re: feature requests for setup > > - Have setup check with the mirror to see if the setup program itself > >has been upgraded. For people who dont read announcements. > > It already does that. > > > - If installing from the local directory, possibly only do the MD5 > > checksum for packages that are actually going to be installed, > > because it now checks every package whenever it starts. Or > > at least after an install cycle is complete, allow an option to go back, > > so the recheck can skipped, or even both these ideas. > > <http://cygwin.com/acronyms/#PTC>. Also see below. > > > - That "packages" directory default. Sometimes setup drops "packages" > > from its default, allowing very wierd directory hierarchies indeed, > > if downloading from somewhere. From bitter experience, I always make > > sure this particular field ends in "packages". > > I don't get this one at all. What are you trying to say? > Hi, i had a bad day yesterday, today I see the little scroll bars between Bin and Src, also the "back" key at the point it asks for the desktop icon. Also I think my packages confusion was from the older setup, because the newer one doesnt do it now. I apologise to the mailing list for most of the points in my post, which are erroneous. What wasnt happenning though, was that I had setup version 2.249.2.10 installed locally, when I went "download from internet", at the ftp://mirror.aarnet.edu.au site, it would install cygwin-1.3.22-1.tar.bz2, which had an old cygwin dll, and not cygwin-1.5.5-1.tar.bz2, which had the new one. The old one would fail with most of the utilities such as ls.exe, with a "__getreent" failure. When I downloaded setup version 2.340.2.5, it found and downloaded the package with the newer dll, as well as others. I think. In my local cache of packages, I had been using experimental packages, as well as a locally compiled and patched snapshot, so this could have something to do with it. -- __ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
feature requests for setup
Hi, I thought I would note some desirable features in setup that would save dickheads such as myself much time. - Have setup check with the mirror to see if the setup program itself has been upgraded. For people who dont read announcements. - If installing from the local directory, possibly only do the MD5 checksum for packages that are actually going to be installed, because it now checks every package whenever it starts. Or at least after an install cycle is complete, allow an option to go back, so the recheck can skipped, or even both these ideas. - That "packages" directory default. Sometimes setup drops "packages" from its default, allowing very wierd directory hierarchies indeed, if downloading from somewhere. From bitter experience, I always make sure this particular field ends in "packages". - Have some of those little popup messages on the title, i.e. b -> binary, s->source, after an interval the only b and s I can think of is bachelors and spinsters. resizeable window perhaps. Dont get me wrong, my admiration for setup is boundless, mainly because it is the only thing that can punch through our corporate firewall, besides internet explorer. Be great to have source for it, or at least a cvs grab utility based on it. -- __ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
pthreads and atexit on cygwin
Hi,
I have a noticed a difference in execution between cygwin and linux for pthreads and
atexit. If exit is called by a thread, then functions lodged with atexit by the main
thread do not get invoked on cygwin, but do get invoked on linux. Because I am unsure
if this difference has been noted by anyone, I am describing it.
My test function is at the end of this message.
Looking at glibc, exit and atexit appear to use a single global pointer (__exit_funcs
in stdlib/exit.c, cxa_atexit.c) whereas the cygwin newlib code
(newlib/libc/stdlib/atexit.c) uses a pthread-keyed datum (macro _REENT) returned by
__getreent(), different for each thread.
While I am no expert on this, logically I prefer the glibc approach,
because if I want something to happen at the end of a thread and to exit a thread I
call pthread_exit and pthread_cleanup_push,
while if I want something to happen when the whole process finishes, I call atexit and
I dont want to worry about what thread
does the terminating.
#include
#include
#include
static pthread_cond_t started = PTHREAD_COND_INITIALIZER;
static pthread_mutex_t a_mutex = PTHREAD_MUTEX_INITIALIZER;
static pthread_t a_thread;
static void exitfunc(void)
{
printf("exit function invoked.\n");
}
static void * thread_routine(void * data)
{
exit(0);
}
int main(int argc, int argv)
{
int r;
r = atexit(exitfunc);
assert(r == 0);
if(argc > 1)return 0;
r = pthread_mutex_lock(&a_mutex);
assert(r == 0);
r = pthread_create(&a_thread, NULL, thread_routine, NULL);
assert(r == 0);
r = pthread_cond_wait(&started, &a_mutex);
assert(r == 0);
return 0;
}
--
__
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Using gdb on cygwin library/dll functions
In answer to my own query, after compiling and installing a snapshot, ensuring an unstripped cygwin1.dll was installed, and setting a breakpoint at and stopping at main, then breakpoints could be set within cygwin library In fact though a bit frustrated yesterday, today i'm quite impressed. -- __ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: snapshot installation confusion
In answer to my own query I copied from /install/* into /usr, where the install directory hierarchy appeared to be rooted. -- __ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: snapshot compilation failure
> Hallo peter, > > Am Mittwoch, 27. August 2003 um 08:31 schriebst du: > > > Please try the latest available perl snapshot test pre-release: > http://anfaenger.de/cygwin-1.5/perl/perl-5.8.1-1.tar.bz2 > > You can use setup.exe to install it, to do so, add this URL to the > mirrors list: http://anfaenger.de/cygwin-1.5 > > Gerrit > -- > =^..^= > Thanks, worked well. -- __ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
snapshot installation confusion
Referring to the faq question "how do i rebuild the tools on my NT box" the instructions are to "install everything", after the "make install" and "make check" steps. I understand the dll swapping trickery, but exactly what directories are to be copied where with the "install everything" step? -- __ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Using gdb on cygwin library/dll functions
How to do this? If I attempt to set a breakpoint at, say, pthread_cancel, I get Cannot access memory at address 0x25 although pthread_cancel exists at 0x5a79f0 according to the map file. If I attempt to link with -static, I get a -lX11 library lookup failure. If I attempt to link in the relevant .o file directly, e.g. pthread.o or thread.o, I get a great many unresolved references. -- __ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
snapshot compilation failure
Attempting to compile the latest snapshot, (by untaring cygwin-src-20030823.tar.bz2 and winsup-src-20030823.tar.bz2 in /, and creating /src as a symbolic link, creating /obj, /install, entering /obj, /src/configure --prefix=/install, then make.) The make fails with libm.a. Relevant messages are: /bin/sh /src/winsup/cygwin/speclib /obj/i686-pc-cygwin/winsup/cygwin/libpthread.a "nm" "ar" /obj/i686-pc-cygwin/winsup/cygwin/libcygwin.a pthread.o thread.o /bin/sh /src/winsup/cygwin/speclib /obj/i686-pc-cygwin/winsup/cygwin/libm.a "nm" "ar" /obj/i686-pc-cygwin/winsup/cygwin/libcygwin.a /obj/i686-pc-cygwin/newlib/libm/libm.a /bin/sh /src/winsup/cygwin/speclib -v /obj/i686-pc-cygwin/winsup/cygwin/libc.a "nm" "ar" /obj/i686-pc-cygwin/winsup/cygwin/libcygwin.a /obj/i686-pc-cygwin/winsup/cygwin/libm.a libpthread.a nm: /obj/i686-pc-cygwin/winsup/cygwin/libm.a: File format not recognized nm: libpthread.a: File format not recognized speclib: couldn't find symbols for /obj/i686-pc-cygwin/winsup/cygwin/libc.a make[2]: *** [/obj/i686-pc-cygwin/winsup/cygwin/libc.a] Error 1 make[2]: Leaving directory `/obj/i686-pc-cygwin/winsup/cygwin' make[1]: *** [cygwin] Error 1 make[1]: Leaving directory `/obj/i686-pc-cygwin/winsup' make: *** [all-target-winsup] Error 2 Looking at libm.a, ar and nm refuse to recognise it, file says it is a current ar archive. it is 93360 bytes. libpthread.a is also not recognised, other ".a" file are though. -- __ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
pthread_cond_timedwait accurate to one second only
Hi. I would like to use this function down to 10 milliseconds accuracy if possible. However upon looking at winsup/cygwin/thread.cc, it uses the function "ftime" and the millisecond field is ignored. All the examples in the winsup testsuite also generally check to 5 seconds only. Is there any inherent reason why finer timing would not work? -- __ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
problem compiling cygwin, make fails in winsup/cygwin
Hi, I am attempting to build cygwin from source. The make fails in i686-pc-cygwin/winsup/cygwin, error is make: *** No rule to make target `/usr/lib/w32api/Makefile', needed by `/lib/'. Stop. Before this point, the following messages were also emitted. Making each object: cc1(plus):warning: changing search order for system directory "/usr/lib/gcc-lib/i686-pc-cygwin/3.2/include" cc1(plus):warning: as it has already been specified as a non-system directory Then immediately before the fatal error: make[2]: Circular /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../../i686-pc-cygwin/lib <- /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../../i686-pc-cygwin/lib dependency dropped (This lib directory did not exist. Creating it has no effect.) To reach this, i did the following 1) Untared cygwin-1.3.22-1-src.tar.bz2 in /usr/local/src of a cygwin computer. 2) created and entered a parallel build directory, cygwin_build. 3) entered the command: ../cygwin-1.3.22-1/configure --prefix=/usr/local/cygwin 4) then went make Where am I doing wrong? Are there any instructions for this? -- __ http://www.linuxmail.org/ Now with e-mail forwarding for only US$5.95/yr Powered by Outblaze -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
