pthread_signal() references illegal memory address

[Kern Sibbald <kern at sibbald dot com>]

Hello,

Please don't think I'm not interested in this if
it takes a bit of time to get back to you ...

See responses below:


On Mon, 2003-05-05 at 19:30, Igor Pechtchanski wrote:
> On 5 May 2003, Kern Sibbald wrote:
> 
> > Hello,
> >
> > On Mon, 2003-05-05 at 18:38, Igor Pechtchanski wrote:
> > > On 5 May 2003, Kern Sibbald wrote:
> > >
> > > > I guess you guys (and gal) really don't want bug
> > > > reports because it is not at all obvious where
> > > > to send them.
> > >
> > > This is the right place.
> >
> > Great.
> >
> > > > Anyway here is one:
> > > >
> > > > Running WinXP Home version.
> > > >
> > > > Using Cygwin 1.3.20
> > > >
> > > > When running my program with LocalSystem userid
> > > > as a service, doing a pthread_kill(thread_id, SIGUSR2)
> > > > causes some sort of memory fault referencing memory at 0x3a
> > > > (or something like that because the program disappears
> > > > poof).
> > > >
> > > > Running as a normal user works fine.
> > >
> > > What's the exact error message (I assume you get a popup box)?
> >
> > No, I get absolutely nothing. Poof and it is gone, well, the
> > service manager knows it went away but not why.
> >
> > A friend ran the program on Win2K and he got:
> >
> >       Instruction at 0x0041276a referenced memory at 0x3c
> >
> > That appears to be somewhere in the cygwin1.dll.
> 
> Try checking the "Allow service to interact with the desktop" box, and you
> should see the error popup on your system too.

My service always interacts with the desktop. It is capable of
doing MessageBox(), and it always has an icon in the system tray
with a menu that works.  

I get absolutely nothing in terms of output of any sort when
the program crashes -- as I said, it goes poof.  This could
be my own fault for trapping signals, but normally during
signal handling there is a considerable amount of printout,
...

> 
> > > Is there a stacktrace file generated?
> >
> > If it is, I don't know where the system put it.
> 
> The system should put it in the directory from which the program is run.

There is no stack dump or any other file in the directory from
which the program (Bacula) executes.

> 
> > >   Did you try setting
> > > "error_start:c:/cygwin/bin/dumper.exe" in your CYGWIN environment
> > > variable?

I doubt this would help much, maybe I am wrong, please see below.

> >
> > No, if you can tell me how to set the environment variable for
> > a service, I'll try it, but since it is a service, I am unlikely
> > to get any output.
> 
> "cygrunsrv --help", or "man cygrunsrv", or see /bin/ssh-host-config for an
> example.  You might also need the "Allow service to interact with desktop"
> bit.

None of the above mentioned things exist on my system. In any case,
I have no problem setting the program up as a service (it installs 
itself with allowing interaction with the desktop by default).

> 
> > > Did you try running the program from the command line in a
> > > LocalSystem-owned shell?
> >
> > I ran it in an rxvt shell under my id and it does not crash.
> > Tell me how to get a LocalSystem owned shell and I will try
> > it.  This is XP Home, so I don't have access to a lot of the
> > XP security dialogs.
> 
> "at <time> /interactive c:\cygwin\bin\bash.exe -i --login"
> (<time> should be current time however long you're willing to wait, at
> least one minute).  "at /?" for help.
> [Note, this works on Win2k, don't know about XP Home].

Yes, your trick works on WinXP Home too. So much for Windows
security!

The interesting thing is that when I run the program under
a rxvt window with the bash shell with the LocalSystem account,
it does NOT crash.  I also ran the program under
a MS DOS shell and I get the same result: it does
not crash.

It crashes only if it is started by the service dialog.

> 
> > > Can you provide a simple testcase that
> > > reproduces your problem?
> >
> > Probably not as my program is some 65K+ lines of code.

> You could try a simple program that calls the offending function (after
> creating some threads, most likely), and see if the problem manifests...


Well, I was considering doing so, since creating a thread
and sending it a signal is a 10 line program. However, this
problem requires the program to run as a service, and that
is a considerable amount of code.

> 
> 
> > I've solved the problem for myself by doing the "signal"
> > a different way, so it is not critical for me but it cost
> > about 8 hours of debugging -- primarily due to the fact that
> > it seems to be dependent on whether or not it is a service.
> >
> > Best regards,
> > Kern
> 
> It's most likely dependent on the value of your CYGWIN variable or some
> permissions (as the service runs as LocalSystem).  Trying the program out
> from a LocalSystem-owned window (see above) should give you some idea of
> what's at fault.

I agree with you, but my CYGWIN environment variable is not set.  

If you have any other ideas I'll try them, otherwise, I'll avoid
using pthread_signal() under CYGWIN.

Best regards,

Kern


--
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/