pthread_signal() references illegal memory address

Igor Pechtchanski pechtcha@cs.nyu.edu
Thu May 8 19:03:00 GMT 2003


On 8 May 2003, Kern Sibbald wrote:

> 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:
> > > > [snip]
> > > > > 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.

Kern,

That's what "cygrunsrv" is for!  It takes *any* command-line program and
turns it into a service. :-D  Try making a small command-line example and
run it as a service using cygrunsrv (you'll have to install the cygrunsrv
package).
	Igor

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

-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Knowledge is an unending adventure at the edge of uncertainty.
  -- Leto II


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



More information about the Cygwin mailing list