Re: strange crashes on invocation

[Reini Urban <rurban at x-ray dot at>]

2010/9/28 Corinna Vinschen:
> On Sep 27 18:32, Pierre A. Humblet wrote:
>> At 07:39 AM 9/27/2010, Corinna Vinschen wrote:
>> >On Sep 26 16:38, Corinna Vinschen wrote:
>> >> Btw., with horror I realized that our dependency to advapi32.dll also
>> >> adds an indirect dependency to msvcrt.dll. ?For some reason I don't
>> >> understand yet, it's not possible to convert the advapi32 entry points
>> >> to all autoloaded entry points. ?Many Cygwin applications don't start
>> >> anymore, for instance mintty or gdb.
>> >
>> >I found the reason why it's not possible to convert advapi32 to a
>> >autoload DLL. ?The problem is a SEGV in the advapi32 function
>> >GetUserNameW. ?For some reason advapi32 crashes in that function if the
>> >application is loadtime linked against advapi32. ?Cygwin calls
>> >GetUserNameW in cygheap_user::init, which is called during Cygwin DLL
>> >initialization. ?Apparently there's some sort of synchronization
>> >problem.
>>
>> Why do we need the user name so early? Does it date back to Win95 when the user
>> shared was using the user name ? For the user fstab, it could be
>> legitimate to insist
>> that the passwd entry exists.
>
> Good point. ?OTOH, fetching USERNAME from the environment might not be
> as bad as I thought at first. ?cygheap_user::init is only called when
> started from a native process. ?Since USERNAME is usually set, we get a
> valid user name which can be used as Cygwin user name if passwd is
> missing. ?And, in the unlikely case that USERNAME is not set *and*
> /etc/passwd is missing, we just don't read the user fstab, as you
> suggest. ?Does that sound feasible?

Sure.
But having a snapshot to test is better.
-- 
Reini Urban