backtrace(3) in Cygwin

backtrace(3) in Cygwin

[David Stacey]

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

Following on from my thread on the main list [1], I have made an initial 
attempt at implementing backtrace(3) and backtrace_symbols(3). This 
still needs a little work - at the moment, the paths in the strings will 
be DOS-style rather than POSIX. However, I wanted to submit an early 
version to make sure you were happy with my approach before I spend more 
time on it.

I've also documented (in the code) the issues surrounding 
backtrace_symbols_fd(3) on Cygwin.

This is my first real submission to the programme - be kind :-)

Dave.

[1] - http://cygwin.com/ml/cygwin/2015-03/msg00198.html


[-- Attachment #2: exec_info.c --]
[-- Type: text/x-csrc, Size: 7786 bytes --]

#include <windows.h>
#include <dbghelp.h>
#include <assert.h>
#include <stdio.h>

/* This implementation of backtrace(3) and backtrace_symbols(3) comes with a
 * number of limitations:
 *
 *    - The maxium number of stack frames is limited by the implementation of
 *      CaptureStackBackTrace() in Windows XP, which can only retrieve a
 *      maximum of 63 frames.
 *
 *    - All of the DbgHelp functions in Windows are not thread safe. This
 *      means that our implementation of the backtrace functions are also not
 *      thread safe.
 *
 *    - The frames returned by this implementation of backtrace(3) include
 *      those those in the Windows kernel. This means that kernel32.dll and
 *      ntdll.dll appear at the bottom end of the stack trace, and obviously
 *      you wouldn't see these on Linux.
 */

/* backtrace() returns a backtrace for the calling program, in the array
 * pointed to by buffer. A backtrace is the series of currently active
 * function calls for the program. Each item in the array pointed to by
 * buffer is of type void *, and is the return address from the corresponding
 * stack frame. The size argument specifies the maximum number of addresses
 * that can be stored in buffer. If the backtrace is larger than size, then
 * the addresses corresponding to the size most recent function calls are
 * returned; to obtain the complete backtrace, make sure that buffer and size
 * are large enough.
 */
int backtrace(void **buffer, int size)
{
    HANDLE process = GetCurrentProcess();
    const int xp_max_frame_depth = 61;
    if (size > xp_max_frame_depth)
        size = xp_max_frame_depth;

    /* Ignore this function when getting the stack frames. */
    SymInitialize(process, NULL, TRUE);
    return CaptureStackBackTrace(1, size, buffer, NULL);
}

/* Given the set of addresses returned by backtrace() in buffer,
 * backtrace_symbols() translates the addresses into an array of strings that
 * describe the addresses symbolically. The size argument specifies the
 * number of addresses in buffer. The symbolic representation of each address
 * consists of the function name (if this can be determined), a hexadecimal
 * offset into the function, and the actual return address (in hexadecimal).
 * The address of the array of string pointers is returned as the function
 * result of backtrace_symbols(). This array is malloc(3)ed by
 * backtrace_symbols(), and must be freed by the caller. (The strings pointed
 * to by the array of pointers need not and should not be freed.)
 */
char **backtrace_symbols(void *const *buffer, int size)
{
    HANDLE process = GetCurrentProcess();
    SYMBOL_INFO *symbol;
    IMAGEHLP_MODULE64 module_info;
    const int chars_needed_to_display_address = 16;
    const int additional_characters = 11;
    int chars_required = 0;
    int i;
    char **result;
    DWORD64 offset;
    char* frame_text;

    symbol = (SYMBOL_INFO*)calloc(sizeof(SYMBOL_INFO) + (MAX_SYM_NAME + 1) * sizeof(char), 1);
    symbol->MaxNameLen = MAX_SYM_NAME;
    symbol->SizeOfStruct = sizeof(SYMBOL_INFO);
    module_info.SizeOfStruct = sizeof(IMAGEHLP_MODULE64);

    /* The glibc documentation doen't say whether the strings we're preparing
     * should contain decorated or undecorated symbol names; it simply states
     * that it should be a 'printable representation' of the frame. The man
     * page doesn't offer any guidance either. We'll use undecorated symbols,
     * as these are probably more helpful.
     */
    SymSetOptions(SymGetOptions() | SYMOPT_UNDNAME);

    /* Compute the amount of memory required to hold the results. Each string
     * takes the following form:
     *
     *     ./prog(myfunc+0x21) [0x8048894]
     *
     * So we need the module name and the symbol name (which will vary in
     * length), two addresses (which we assume are 64 bits and therefore
     * require 16 characters each), ten other characters (brackets, spaces,
     * etc.) and a terminating NULL.
     *
     * We also need a string lookup table, which contains pointers to these
     * strings. The string lookup table comes first in memory, followed by
     * the strings themselves.
     */
    chars_required = size * sizeof(char*);
    for (i = 0; i < size; ++i)
    {
        if ((SymFromAddr(process, (DWORD64)(buffer[i]), 0, symbol)) &&
            (SymGetModuleInfo64(process, symbol->Address, &module_info)))
        {
            chars_required += strlen(symbol->Name) + strlen(module_info.LoadedImageName) +
                (2 * chars_needed_to_display_address) + additional_characters;
        }
    }

    /* Allocate enough memory to hold the strings and the string lookup
     * table. This memory buffer is returned once it has been populated, and
     * it is the responsibility of the caller to free(3) the memory.
     */
    result = (char**) malloc(chars_required);

    /* Now populate the string lookup table and the strings with the text
     * describing a frame. The pointer 'frame_text' is within the buffer we
     * have just allocated and points to the start of the next string to
     * write.
     */
    if (result)
    {
        frame_text = (char*) (result + size);
        for (i = 0; i < size; ++i)
        {
            result[i] = frame_text;

            if ((SymFromAddr(process, (DWORD64)(buffer[i]), &offset, symbol)) &&
                (SymGetModuleInfo64(process, symbol->Address, &module_info)))
            {
                frame_text += 1 + sprintf(frame_text, "%s(%s+0x%lx) [0x%lx]",
                    module_info.LoadedImageName, symbol->Name, (unsigned long)offset,
                    (unsigned long)buffer[i]);
            }
            else
                frame_text += 1 + sprintf(frame_text, "[0x%lx]", (unsigned long)buffer[i]);
        }
        assert(frame_text < (char*)result + chars_required);
    }

    free(symbol);
    return result;
}

/* backtrace_symbols_fd() takes the same buffer and size arguments as
 * backtrace_symbols(), but instead of returning an array of strings to the
 * caller, it writes the strings, one per line, to the file descriptor fd.
 * backtrace_symbols_fd() does not call malloc(3), and so can be employed in
 * situations where the latter function might fail.
 */
void backtrace_symbols_fd(void *const *buffer, int size, int fd)
{
    /* A Cygwin implementation of backtrace_symbols_fd(3) is going to be
     * somewhat problematic and will demand a compromise at some point along
     * the way. The problem is how to allocate memory for the SYMBOL_INFO
     * structure, given that we're not supposed to use heap memory. Windows
     * defines MAX_SYM_NAME as 2000 characters, and clearly we shouldn't go
     * trying to allocate that much memory on the stack.
     *
     * Then there's the issue of how we actually get the data out to the file
     * descriptor supplied. If Cygwin supports dprintf(3) then that's all
     * well and good - but if not we'll have to use write(2), and that
     * involves allocating another buffer to hold the text we want to write
     * out - and that means a second copy of our long symbol name on the
     * stack.
     *
     * Clearly a compromise is needed. Here are some options:
     *
     *    - Instead of MAX_SYM_NAME, use a much, much smaller value (say
     *      256). Then we could allocate all the memory we need on the stack
     *      and still display the majority of symbol names.
     *
     *    - Allocate heap memory anyway, irrespective of what the man page
     *      says. In environments where Cygwin is run (i.e. the Windows
     *      desktop), heap is probably plentiful, so does this matter?
     *
     *    - Do not provide backtrace_symbols_fd(3) at all.
     *
     * For the moment, I'll take the latter of those options.
     */
}

Re: backtrace(3) in Cygwin

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 5855 bytes --]

Hi David,


thanks for hacking on Cygwin in the first place.

Unfortunately there are some preliminaries before I can take a closer
look, namely the copyright assignment we need from everybody who's
providing more than just trivial patches to Cygwin, see
https://cygwin.com/contrib.html, the "Before you get started" section.
Fill out https://cygwin.com/assign.txt and send it to the address given
in the pamphlet.  If you're writing code for Cygwin only in your spare
time, forget the part about your employer.

Having said that...

On Mar 15 19:51, David Stacey wrote:
> Following on from my thread on the main list [1], I have made an initial
> attempt at implementing backtrace(3) and backtrace_symbols(3). This still
> needs a little work - at the moment, the paths in the strings will be
> DOS-style rather than POSIX.

Yuk! :)

> However, I wanted to submit an early version to
> make sure you were happy with my approach before I spend more time on it.
> 
> I've also documented (in the code) the issues surrounding
> backtrace_symbols_fd(3) on Cygwin.
> 
> This is my first real submission to the programme - be kind :-)

I will.  But  submissions almost always have to jump a couple of hurdles
(i.e., see how many iterations some patches need to make it into the
official Linux kernel) , so I'm asking for your patience in return, ok?
Any criticism here is not meant personally.

Also, it's a good idea to scan over https://cygwin.com/contrib.html.
Really.

Having said *that*...

* While you're already providing code, I'm missing a bit of discussion
  first.  You didn't respond to
  https://cygwin.com/ml/cygwin/2015-03/msg00206.html at all.

  Of course, it's ideally discussed on cygwin-developers anyway, but a
  discussion should ideally preceed a code submission :}

  My main point: Only *one* implementation of the stack walk code,
  not one for generating stackdumps and one for implementing backtrace(3).

  That doesn't mean we have to stick to the current stack_info class in
  exceptions.cc, but it's certainly still a good idea to implement the
  entire stack walking stuff in a class which allows usage from both
  places.


* Your coding style doesn't match the GNU coding style, see
  https://cygwin.com/contrib.html.  For correct formatting, indent is
  your friend.  It's generating GNU coding by default.  Also, while
  I'm sympathetic with comments preceeding every line with an asterisk,
  usually comments are supposed to look like this:

  /* comment line 1
     line 2
     line 3
     line 4. */


A few more comments inline:

> int backtrace(void **buffer, int size)
> {
>     HANDLE process = GetCurrentProcess();
>     const int xp_max_frame_depth = 61;
>     if (size > xp_max_frame_depth)
>         size = xp_max_frame_depth;
> 
>     /* Ignore this function when getting the stack frames. */
>     SymInitialize(process, NULL, TRUE);

This looks a bit too simple.  Most of the time we have stripped
executables, but the symbol files are available via the debuginfo
packages.  I don't know if the symbols *have* to be available as .pdb
files, but if this functionality also understands normal symbol tables
inside of executable files we might have a chance here to use the
debuginfo files for symbol evaluation.

>     /* Now populate the string lookup table and the strings with the text
>      * describing a frame. The pointer 'frame_text' is within the buffer we
>      * have just allocated and points to the start of the next string to
>      * write.
>      */
>     if (result)
>     {
>         frame_text = (char*) (result + size);
>         for (i = 0; i < size; ++i)
>         {
>             result[i] = frame_text;
> 
>             if ((SymFromAddr(process, (DWORD64)(buffer[i]), &offset, symbol)) &&
>                 (SymGetModuleInfo64(process, symbol->Address, &module_info)))
>             {
>                 frame_text += 1 + sprintf(frame_text, "%s(%s+0x%lx) [0x%lx]",
>                     module_info.LoadedImageName, symbol->Name, (unsigned long)offset,
>                     (unsigned long)buffer[i]);
>             }
>             else
>                 frame_text += 1 + sprintf(frame_text, "[0x%lx]", (unsigned long)buffer[i]);
>         }
>         assert(frame_text < (char*)result + chars_required);

Don't use assert here.  Generate an error instead.

> /* backtrace_symbols_fd() takes the same buffer and size arguments as
>  * backtrace_symbols(), but instead of returning an array of strings to the
>  * caller, it writes the strings, one per line, to the file descriptor fd.
>  * backtrace_symbols_fd() does not call malloc(3), and so can be employed in
>  * situations where the latter function might fail.
>  */
> void backtrace_symbols_fd(void *const *buffer, int size, int fd)
> {
>     /* A Cygwin implementation of backtrace_symbols_fd(3) is going to be
>      * somewhat problematic and will demand a compromise at some point along
>      * the way. The problem is how to allocate memory for the SYMBOL_INFO
>      * structure, given that we're not supposed to use heap memory. Windows
>      * defines MAX_SYM_NAME as 2000 characters, and clearly we shouldn't go
>      * trying to allocate that much memory on the stack.

This is Windows.  What you can do to make sure not to use any existing
heap is this:  Create your own Windows heap and use this exclusively
from the C++ class implementing the stack walk.  If creating the heap
fails, we're screwed, but otherwise you can allocate memory from a
pristine heap not related to other stuff in the application.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: backtrace(3) in Cygwin

[David Stacey]

On 16/03/15 10:07, Corinna Vinschen wrote:
> Unfortunately there are some preliminaries before I can take a closer
> look, namely the copyright assignment we need from everybody who's
> providing more than just trivial patches to Cygwin, see
> https://cygwin.com/contrib.html, the "Before you get started" section.
> Fill out https://cygwin.com/assign.txt and send it to the address given
> in the pamphlet.  If you're writing code for Cygwin only in your spare
> time, forget the part about your employer.

I'm hoping that this won't be a problem. I'm more than happy to assign 
my own copyright to Red Hat. My employer has no claim to work I do in my 
own time on my own equipment. However, Cygwin might be a grey area, as 
we use Cygwin extensively in our development work. So I've already asked 
my employer to sign the copyright and patent waiver. Assuming this is 
signed, I'll send both parts together.

So let's proceed assuming that this is going to happen.

> But  submissions almost always have to jump a couple of hurdles
> (i.e., see how many iterations some patches need to make it into the
> official Linux kernel) , so I'm asking for your patience in return, ok?

Submitting code to the Linux kernel also involves one of us ranting and 
shouting obscenities, but hopefully we don't have to emulate Linux that 
closely ;-)

> * While you're already providing code, I'm missing a bit of discussion
>    first.  You didn't respond to
>    https://cygwin.com/ml/cygwin/2015-03/msg00206.html at all.
>
>    Of course, it's ideally discussed on cygwin-developers anyway, but a
>    discussion should ideally preceed a code submission :}

Sorry - that's my fault for not understanding. The code I posted was in 
no way a finished item; it was just to get the discussion started. And I 
wasn't trying to avoid a discussion - in fact quite the opposite. 
Talking about code is *so* much more interesting when there's actual 
code to talk about! I simply presented one way in which it /might/ work, 
but...

>    My main point: Only *one* implementation of the stack walk code,
>    not one for generating stackdumps and one for implementing backtrace(3).
>
>    That doesn't mean we have to stick to the current stack_info class in
>    exceptions.cc, but it's certainly still a good idea to implement the
>    entire stack walking stuff in a class which allows usage from both
>    places.

... it sounds like you have an idea of how you'd like this implemented - 
and that's fine. This is your project, so I'll keep reworking the code 
until we're both happy. I haven't had chance to look at the code you 
mentioned yet, but I will. I'm rather busy this week, so it might be a 
while before I come back to you.

> * Your coding style doesn't match the GNU coding style,

That's OK. I've been long enough in the coding game that I can write 
code in anybody's style. Now I know what you want, future code will 
adhere to the GNU standard (hopefully). A couple of questions not 
covered in the standard:

   - I assume from the examples that indentation is two spaces (I didn't 
see this stated explicitly). And I assume that you always use spaces and 
never tab characters;

   - in comments, do you prefer English spellings or their American 
equivalents?

> Don't use assert here.  Generate an error instead.

Please could you point me at an example of error reporting elsewhere in 
the Cygwin code so I can see how you'd like that doing.

>
>> /* backtrace_symbols_fd() takes the same buffer and size arguments as
>>   * backtrace_symbols(), but instead of returning an array of strings to the
>>   * caller, it writes the strings, one per line, to the file descriptor fd.
>>   * backtrace_symbols_fd() does not call malloc(3), and so can be employed in
>>   * situations where the latter function might fail.
>>   */
>> void backtrace_symbols_fd(void *const *buffer, int size, int fd)
>> {
>>      /* A Cygwin implementation of backtrace_symbols_fd(3) is going to be
>>       * somewhat problematic and will demand a compromise at some point along
>>       * the way. The problem is how to allocate memory for the SYMBOL_INFO
>>       * structure, given that we're not supposed to use heap memory. Windows
>>       * defines MAX_SYM_NAME as 2000 characters, and clearly we shouldn't go
>>       * trying to allocate that much memory on the stack.
> This is Windows.  What you can do to make sure not to use any existing
> heap is this:  Create your own Windows heap and use this exclusively
> from the C++ class implementing the stack walk.  If creating the heap
> fails, we're screwed, but otherwise you can allocate memory from a
> pristine heap not related to other stuff in the application.

I've done a little investigation, and it seems that the stack size on 
Cygwin is much larger than I thought. So I should be able to allocate a 
couple of 2k buffers on the stack without any problem. Coverity (for 
instance) will only start grumbling about excessive stack use once a 
function has used 10k. However, if I use your existing stack walker 
class then backtrace_symbols_fd(3) will be implemented differently anyway.

Thank you for your feedback, and apologies once again for any 
misunderstanding.

Dave.

Re: backtrace(3) in Cygwin

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 7235 bytes --]

Hi David,

On Mar 16 22:21, David Stacey wrote:
> On 16/03/15 10:07, Corinna Vinschen wrote:
> >Unfortunately there are some preliminaries before I can take a closer
> >look, namely the copyright assignment we need from everybody who's
> >providing more than just trivial patches to Cygwin, see
> >https://cygwin.com/contrib.html, the "Before you get started" section.
> >Fill out https://cygwin.com/assign.txt and send it to the address given
> >in the pamphlet.  If you're writing code for Cygwin only in your spare
> >time, forget the part about your employer.
> 
> I'm hoping that this won't be a problem. I'm more than happy to assign my
> own copyright to Red Hat. My employer has no claim to work I do in my own
> time on my own equipment. However, Cygwin might be a grey area, as we use
> Cygwin extensively in our development work. So I've already asked my
> employer to sign the copyright and patent waiver. Assuming this is signed,
> I'll send both parts together.
> 
> So let's proceed assuming that this is going to happen.

Cool, thanks.  However, it doesn't depend on how and where you use
Cygwin, it depends on how and where you hack on Cygwin.  Not Cygwin
packages, not python scripts running under Cygwin, just Cygwin itself as
it's stored in the git repo.  Even minus newlib due to the different
licensing situation.

> >But  submissions almost always have to jump a couple of hurdles
> >(i.e., see how many iterations some patches need to make it into the
> >official Linux kernel) , so I'm asking for your patience in return, ok?
> 
> Submitting code to the Linux kernel also involves one of us ranting and
> shouting obscenities, but hopefully we don't have to emulate Linux that
> closely ;-)

I don't think I can emulate Linus for any length of time, really :}

> >* While you're already providing code, I'm missing a bit of discussion
> >   first.  You didn't respond to
> >   https://cygwin.com/ml/cygwin/2015-03/msg00206.html at all.
> >
> >   Of course, it's ideally discussed on cygwin-developers anyway, but a
> >   discussion should ideally preceed a code submission :}
> 
> Sorry - that's my fault for not understanding. The code I posted was in no
> way a finished item; it was just to get the discussion started.

I kind of thought so.  More or less.

> And I wasn't
> trying to avoid a discussion - in fact quite the opposite. Talking about
> code is *so* much more interesting when there's actual code to talk about! I
> simply presented one way in which it /might/ work, but...
> 
> >   My main point: Only *one* implementation of the stack walk code,
> >   not one for generating stackdumps and one for implementing backtrace(3).
> >
> >   That doesn't mean we have to stick to the current stack_info class in
> >   exceptions.cc, but it's certainly still a good idea to implement the
> >   entire stack walking stuff in a class which allows usage from both
> >   places.
> 
> ... it sounds like you have an idea of how you'd like this implemented - and
> that's fine. This is your project, so I'll keep reworking the code until
> we're both happy. I haven't had chance to look at the code you mentioned
> yet, but I will. I'm rather busy this week, so it might be a while before I
> come back to you.

No worries.  I don't have a fixed idea in mind, it's just that we're
using C++ anyway, and since we need the stack trace in more than one
place, the underlying implementation for both, the stackdump and
the backtrace(3) facility, should be a single piece of code or class.

> >* Your coding style doesn't match the GNU coding style,
> 
> That's OK. I've been long enough in the coding game that I can write code in
> anybody's style. Now I know what you want, future code will adhere to the
> GNU standard (hopefully). A couple of questions not covered in the standard:
> 
>   - I assume from the examples that indentation is two spaces (I didn't see
> this stated explicitly). And I assume that you always use spaces and never
> tab characters;

Not quite.  In vi terms, sw=2,ts=8.  Max line length 80.

>   - in comments, do you prefer English spellings or their American
> equivalents?

Yes. ;)

> >Don't use assert here.  Generate an error instead.
> 
> Please could you point me at an example of error reporting elsewhere in the
> Cygwin code so I can see how you'd like that doing.

What I meant was, just do the usual error action for backtrace.  AFAICS,
there's only a NULL value returned without declaration of setting errno
or something.

As for debug output, grep for, e.g. debug_printf, syscall_printf, etc. 
This is an internal implementation using slightly different format
characters, see smallprint.cc line 95ff.
There were fixed rules for when using when at one point, but these days
it's been used a bit arbitrarily in some places.  Just use common sense.

> >>/* backtrace_symbols_fd() takes the same buffer and size arguments as
> >>  * backtrace_symbols(), but instead of returning an array of strings to the
> >>  * caller, it writes the strings, one per line, to the file descriptor fd.
> >>  * backtrace_symbols_fd() does not call malloc(3), and so can be employed in
> >>  * situations where the latter function might fail.
> >>  */
> >>void backtrace_symbols_fd(void *const *buffer, int size, int fd)
> >>{
> >>     /* A Cygwin implementation of backtrace_symbols_fd(3) is going to be
> >>      * somewhat problematic and will demand a compromise at some point along
> >>      * the way. The problem is how to allocate memory for the SYMBOL_INFO
> >>      * structure, given that we're not supposed to use heap memory. Windows
> >>      * defines MAX_SYM_NAME as 2000 characters, and clearly we shouldn't go
> >>      * trying to allocate that much memory on the stack.
> >This is Windows.  What you can do to make sure not to use any existing
> >heap is this:  Create your own Windows heap and use this exclusively
> >from the C++ class implementing the stack walk.  If creating the heap
> >fails, we're screwed, but otherwise you can allocate memory from a
> >pristine heap not related to other stuff in the application.
> 
> I've done a little investigation, and it seems that the stack size on Cygwin
> is much larger than I thought.

For the main thread 2 Megs, for other threads 1 Meg by default.
However, you don't know what's left.  The thread you're called from
could be low on stack already.

> So I should be able to allocate a couple of
> 2k buffers on the stack without any problem. Coverity (for instance) will
> only start grumbling about excessive stack use once a function has used 10k.
> However, if I use your existing stack walker class then
> backtrace_symbols_fd(3) will be implemented differently anyway.
> 
> Thank you for your feedback, and apologies once again for any
> misunderstanding.

No apologies necessary, not at all!  I'm happy to discuss this stuff
further.  It's always nice to have somebody else hacking on Cygwin.


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: backtrace(3) in Cygwin

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

Hi David,

On Mar 17 09:57, Corinna Vinschen wrote:
> On Mar 16 22:21, David Stacey wrote:
> > On 16/03/15 10:07, Corinna Vinschen wrote:
> > >Unfortunately there are some preliminaries before I can take a closer
> > >look, namely the copyright assignment we need from everybody who's
> > >providing more than just trivial patches to Cygwin, see
> > >https://cygwin.com/contrib.html, the "Before you get started" section.
> > >Fill out https://cygwin.com/assign.txt and send it to the address given
> > >in the pamphlet.  If you're writing code for Cygwin only in your spare
> > >time, forget the part about your employer.
> > 
> > I'm hoping that this won't be a problem. I'm more than happy to assign my
> > own copyright to Red Hat. My employer has no claim to work I do in my own
> > time on my own equipment. However, Cygwin might be a grey area, as we use
> > Cygwin extensively in our development work. So I've already asked my
> > employer to sign the copyright and patent waiver. Assuming this is signed,
> > I'll send both parts together.
> > 
> > So let's proceed assuming that this is going to happen.

FYI, as I just wrote on the cygwin ML, legal gave us permission to
collect the copyright assignments as PDF.   Print it, sign it, scan as
PDF, and send to ges-info AT redhat DOT com.  That's all from now on!


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: backtrace(3) in Cygwin

[David Stacey]

On 20/03/15 19:15, Corinna Vinschen wrote:
> On Mar 17 09:57, Corinna Vinschen wrote:
>> On Mar 16 22:21, David Stacey wrote:
>>> On 16/03/15 10:07, Corinna Vinschen wrote:
>>>> Unfortunately there are some preliminaries before I can take a closer
>>>> look, namely the copyright assignment we need from everybody who's
>>>> providing more than just trivial patches to Cygwin, see
>>>> https://cygwin.com/contrib.html, the "Before you get started" section.
>>>> Fill outhttps://cygwin.com/assign.txt  and send it to the address given
>>>> in the pamphlet.  If you're writing code for Cygwin only in your spare
>>>> time, forget the part about your employer.
>>>   
>>> I'm hoping that this won't be a problem. I'm more than happy to assign my
>>> own copyright to Red Hat. My employer has no claim to work I do in my own
>>> time on my own equipment. However, Cygwin might be a grey area, as we use
>>> Cygwin extensively in our development work. So I've already asked my
>>> employer to sign the copyright and patent waiver. Assuming this is signed,
>>> I'll send both parts together.
>>>   
>>> So let's proceed assuming that this is going to happen.
> FYI, as I just wrote on the cygwin ML, legal gave us permission to
> collect the copyright assignments as PDF.   Print it, sign it, scan as
> PDF, and send to ges-info AT redhat DOT com.  That's all from now on!

Thanks for letting me know - hopefully I can get this sent next week.

Dave.