Crash in xserv 4.3.0-40

Crash in xserv 4.3.0-40

[Øyvind Harboe]

Hi Harold,

I'll be sure to follow up on your latest testing tips.

Q: is there any reason not to include symbol information in your testing builds?

Read on....


However, here are the latest and greatest:

- I'm pretty sure that the crash isn't there when I compiled and installed the 
sources as I described.
- I've recently discovered core dumps! Here is a post
that describes it a bit: http://www.cygwin.com/ml/cygwin-patches/2000-q3/msg00041.html

So,

armed with core dumps, my strategy is as follows:

- uninstall everything and reinstall cygwin from scratch w/latest xserv.
- add the following line to the beginning of startxwin.bat

set cygwin=error_start=c:\cygwin\bin\dumper.exe

- wait for the crash
- Recompile w/debug info
- Wait for crash
- Coredump anyone? :-)




Øyvind

enableing GL overlays

[Bruce Dobrin]

Hi,
 I'm just getting back into cyg/xfree after doint other things for a bit.
I'm wondering how to turn on Overlays? I know on Linux I just turn them on
in the Graphics Device Section in the XF86Config file (Option "Overlay"
"on"), I understand the cyg/xfree is driver independent, using Direct Draw
or somesuch thing.  I made sure that Overlays were enabled in the windows
driver,  but I still get errors such as this one

AppWindow::createWindow > could not create overlay visual (try `glxinfo' to
check for availability on your graphics hardware), (sev = 5)


I looked up enableing overlays in the Mailing list and Docs,  but didn't
find anything relevant..

Thanks,  Bruce D.
dobrin@imageworks.com

Re: enableing GL overlays

[Alexander Gottwald]

Bruce Dobrin wrote:

> Hi,
>  I'm just getting back into cyg/xfree after doint other things for a bit.
> I'm wondering how to turn on Overlays? I know on Linux I just turn them on
> in the Graphics Device Section in the XF86Config file (Option "Overlay"
> "on"), I understand the cyg/xfree is driver independent, using Direct Draw
> or somesuch thing.  I made sure that Overlays were enabled in the windows
> driver,  but I still get errors such as this one
>
> AppWindow::createWindow > could not create overlay visual (try `glxinfo' to
> check for availability on your graphics hardware), (sev = 5)

Cygwin/X has no hardware accelerated OpenGL.

bye
    ago

NP: Iris - Saving Time (Original Demo)
-- 
 Alexander.Gottwald@informatik.tu-chemnitz.de
 http://www.gotti.org           ICQ: 126018723

Re: Crash in xserv 4.3.0-40

[Harold L Hunt II]

Øyvind,

Øyvind Harboe wrote:

> Hi Harold,
> 
> I'll be sure to follow up on your latest testing tips.

Okay.

> Q: is there any reason not to include symbol information in your testing builds?

I have seen people asking this since -39 was posted (I believe).  There 
must be some confusion, because -39 and -40 are not 'test' builds.  They 
are 'curr'.  So, including symbol information the testing builds 
wouldn't help with your problem... you have an observed crash in the 
'curr' build, not a 'test' build.

With that being said, I'll address the issue of symbol information:

1) If I include symbol information and there are no crashes, then people 
will complain (don't argue with me, they *will* complain) about the size 
of the download being X KB larger than it had to be.

2) If I do include symbol information and there are crashes, then only 
once every year or so will someone actually bother to do a proper debug 
for me anyhow.

3) A non-stripped build of XWin.exe isn't particularly useful... I 
generally already know which function the crash is in.  Anything short 
of a line number won't do me much good.

4) Getting line numbers from users and cross checking my source files to 
make sure that I've got the right source, plus keeping around an 
elaborate system of stored releases, etc. is not something that I care 
to do.  Thus, there won't be much good for people to send me stackdumps, 
etc.  I'm not going to change this because I have defined an upper limit 
on how much time I will spend on Cygwin/X stuff and I am already *way* 
over that limit.  Feel free to start performing this service yourself. 
I don't think it will get much use, then you will figure out why I am 
not interested in it :)

5) Including full debug symbols (-g) isn't possible with my current 
setup inless I keep my debug build tree up to date, which is tough since 
I'm doing so much work on other things that my CPU is usually pegged at 
100%.  I don't have extra time to be doing debug builds of XWin.exe in 
addition to the standard builds.  I have no interest in doing a debug 
build as the default and stripping the executables either.  Just not 
interested in that since it takes more disk space and is slower 
(probably due to I/O limitations).

So, if anyone sees someone else asking about debug symbols, please crack 
them upside the head for me so I don't have to say all of this again.

> Read on....
> 
> 
> However, here are the latest and greatest:
> 
> - I'm pretty sure that the crash isn't there when I compiled and installed the 
> sources as I described.
> - I've recently discovered core dumps! Here is a post
> that describes it a bit: http://www.cygwin.com/ml/cygwin-patches/2000-q3/msg00041.html

This looks a heck of a lot more useful than including massive amounts of 
symbols.  I have always wanted to look into core dumps further, but 
haven't had a chance yet.

> So,
> 
> armed with core dumps, my strategy is as follows:
> 
> - uninstall everything and reinstall cygwin from scratch w/latest xserv.

Interesting note of the day: if you are doing local builds of Cygwin/X 
and installing them to test things, do what I do:

1) Rename /usr/X11R6 to /usr/X11R6_default

2) Rename /etc/X11 to /etc/X11_default

3) If you didn't build the fonts (saves about an hour), then *cut* the 
following directory in Windows Explorer and paste it in the second 
directory:
/usr/X11R6_default/lib/X11/fonts
/usr/X11R6/lib/X11/fonts

4) Test away

5) When you want to revert, or temporarily revert, just move your 
directories out of the way:
/usr/X11R6 -> /usr/X11R6_local
/usr/X11R6_default -> /usr/X11R6
/etc/X11 -> /etc/X11_local
/etc/X11_default -> /etc/X11
Cut /usr/X11R6_local/lib/X11/fonts and paste /usr/X11R6/lib/X11/fonts

6) That way you don't screw up your Cygwin installation and you don't 
have to keep reinstalling things when you are done testing for a little bit.

The reason I cut and paste the fonts directory is because it contains 
thousands of files; it takes anywhere from 20 minutes to an hour just to 
copy that many files on Win32.  Cutting and pasting is instantaneous.

> - add the following line to the beginning of startxwin.bat
> 
> set cygwin=error_start=c:\cygwin\bin\dumper.exe
> 
> - wait for the crash
> - Recompile w/debug info
> - Wait for crash
> - Coredump anyone? :-)

Cool, let us know how it goes.

Harold

Re: Crash in xserv 4.3.0-40

[Christopher Faylor]

On Thu, Jan 15, 2004 at 06:02:24PM -0500, Harold L Hunt II wrote:
>With that being said, I'll address the issue of symbol information:
>
>1) If I include symbol information and there are no crashes, then people 
>will complain (don't argue with me, they *will* complain) about the size 
>of the download being X KB larger than it had to be.

Newer versions of binutils allow you to split symbol information into a
separate file which gdb understands.  I've been meaning to release a
version of gdb and binutils which can do this for a while and will probably
do this as soon as I'm out from under my current mountain of work.

cgf

Re: Crash in xserv 4.3.0-40

[Earle F. Philhower III]

Howdy Harold, Christopher:

At 06:06 PM 1/15/2004 -0500, you wrote:
>On Thu, Jan 15, 2004 at 06:02:24PM -0500, Harold L Hunt II wrote:
> >With that being said, I'll address the issue of symbol information:
> >1) If I include symbol information and there are no crashes, then people
> >will complain (don't argue with me, they *will* complain) about the size
> >of the download being X KB larger than it had to be.
>Newer versions of binutils allow you to split symbol information into a
>separate file which gdb understands.  I've been meaning to release a
>version of gdb and binutils which can do this for a while and will probably
>do this as soon as I'm out from under my current mountain of work.

Another option is to generate a link map file when you do the final
compile.  It's just a text file of 4KB or so and you can manually reference
the failing address from a stackdump into a routine name.  For my commercial
software I've found this is often enough to figure out what's wrong
without worrying about distributing symbol files or the extra size
associated with them.

-Earle F. Philhower, III
  earle@ziplabel.com
  cdrlabel - ZipLabel - FlpLabel
  http://www.cdrlabel.com