[Bug gdb/15650] New: xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[Bug gdb/15650] New: xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[edderic at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

            Bug ID: 15650
           Summary: xemacs gdb cleanups.c:264: internal-error:
                    restore_my_cleanups: Assertion '*pmy_chain ==
                    SENTINEL_CLEANUP' failed
           Product: gdb
           Version: 7.6
            Status: NEW
          Severity: critical
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: edderic at gmail dot com

>From my StackOverflow post:

http://stackoverflow.com/questions/17052457/xemacs-gdb-cleanups-c264-internal-error-restore-my-cleanups-assertion-pmy

I tried running GDB, version 7.6.50.20130508-cvs (cygwin-special), on Xemacs
version 21.4.21 but I get the following error:

/netrel/src/gdb-7.6.50-2/gdb/cleanups.c:264: internal-error:
restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed
A problem internal to GDB has been detected,
further debugging may prove unreliable 
GDB by itself works fine on Cygwin. On the Cygwin terminal, I did:

g++ -g -o HelloWorld HelloWorld.cpp 
to get the executable, and wrote

gdb HelloWorld.exe 
and then

r
and it worked perfectly. I then did

gdb -v
and the version turned out to be the same as the gdb used by xemacs, so it
seems that the error must be related to the interaction of gdb and xemacs,
instead of it being a gdb problem?

I found that some people had the same, or similar, issue:

http://old.nabble.com/-RFA--dangling-cleanup-in-find_frame_funname-td35521450.html

Any ideas? Thanks in advance!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[edderic at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

edderic at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://stackoverflow.com/qu
                   |                            |estions/17052457/xemacs-gdb
                   |                            |-cleanups-c264-internal-err
                   |                            |or-restore-my-cleanups-asse
                   |                            |rtion-pmy
                 CC|                            |edderic at gmail dot com
   Target Milestone|---                         |7.6

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at redhat dot com

--- Comment #1 from Tom Tromey <tromey at redhat dot com> ---
The thing that would be most helpful is a stack trace of gdb at the
point of failure.

This sort of bug is generally easy to fix once its location is known.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[edderic at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #2 from edderic at gmail dot com ---
Hey Tom,

How can I get a stack trace of gdb in xemacs?


Thanks,
Edderic


(In reply to Tom Tromey from comment #1)
> The thing that would be most helpful is a stack trace of gdb at the
> point of failure.
> 
> This sort of bug is generally easy to fix once its location is known.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #3 from Tom Tromey <tromey at redhat dot com> ---
What I would do is wait for the crash, then attach another gdb to the
crashing gdb using the "attach" command.  Then "bt".
Alternatively a core dump would work just as well.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

Jan Kratochvil <jan.kratochvil at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jan.kratochvil at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[edderic at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #4 from edderic at gmail dot com ---
(In reply to Tom Tromey from comment #3)
> What I would do is wait for the crash, then attach another gdb to the
> crashing gdb using the "attach" command.  Then "bt".
> Alternatively a core dump would work just as well.

gdb in xemacs after the error asked me if I wanted to create a core file:
"Create a core file of GDB? (y or n)"

I typed "y" and pressed "Enter"

And then it said Inferior GDB exited abnormally with code 1.

I then found gdb.exe.stackdump and here's what it said:

Stack trace:
Frame     Function  Args



That's it...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #5 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
core file probably does not work in the cygwin environment well.
Therefore try to attach new GDB to the crashed GDB at the moment it is asking
"Create a core file..." and type "by" in the new GDB then.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[edderic at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #6 from edderic at gmail dot com ---
(In reply to Jan Kratochvil from comment #5)
> core file probably does not work in the cygwin environment well.
> Therefore try to attach new GDB to the crashed GDB at the moment it is
> asking "Create a core file..." and type "by" in the new GDB then.

Hey Jan,

>From Cygwin, I wrote "gdb xemacs" and then "r"
and got these while xemacs is running:

Starting program: /usr/bin/xemacs-21.4.22.exe
[New Thread 4064.0x1670]
[New Thread 4064.0x15f0]
[New Thread 4064.0xb78]
[Thread 4064.0x15f0 exited with code 0]
[New Thread 4064.0x884]
[New Thread 4064.0x1558]
[New Thread 4064.0x770]
[New Thread 4064.0x1578]
[New Thread 4064.0x15f4]
[New Thread 4064.0xaa8]
[New Thread 4064.0x1650]
[New Thread 4064.0x16c0]
[New Thread 4064.0x158c]
[New Thread 4064.0xe9c]
[Thread 4064.0xe9c exited with code 0]
[New Thread 4064.0x1454]
[New Thread 4064.0x1594]
[New Thread 4064.0x1744]
[New Thread 4064.0x1514]
[New Thread 4064.0x1414]
[New Thread 4064.0x108c]
BFD: /cygdrive/c/Windows/SysWOW64/WMVCore.DLL: Warning: Ignoring section flag
IM                                  AGE_SCN_MEM_NOT_PAGED in section .reloc
[New Thread 4064.0x17b4]
[New Thread 4064.0x1208]
[Thread 4064.0x1208 exited with code 0]
[New Thread 4064.0x14dc]
[Thread 4064.0x14dc exited with code 0]
[Thread 4064.0x15f4 exited with code 0]
[New Thread 4064.0xd7c]
[New Thread 4064.0x1338]
[Thread 4064.0x16c0 exited with code 0]
[Thread 4064.0x17b4 exited with code 0]
[Thread 4064.0xaa8 exited with code 0]
[Thread 4064.0x1744 exited with code 0]
[Thread 4064.0x1650 exited with code 0]
[Thread 4064.0x1454 exited with code 0]
[Thread 4064.0x1594 exited with code 0]
[Thread 4064.0x1414 exited with code 0]
[Thread 4064.0x1578 exited with code 0]
[Thread 4064.0x1514 exited with code 0]
[Thread 4064.0x158c exited with code 0]


then I ran gdb in xemacs and got the error (assert failure).  Then I got the
"create a core file" question and I did 'attach' but the thing would only
accept a yes (y) or no (n) for an answer...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[edderic at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #7 from edderic at gmail dot com ---
(In reply to Jan Kratochvil from comment #5)
> core file probably does not work in the cygwin environment well.
> Therefore try to attach new GDB to the crashed GDB at the moment it is
> asking "Create a core file..." and type "by" in the new GDB then.

OK I tried something new:

>From cygwin terminal, I ran xemacs as a background process via "xemacs &"
which gave me the PID 6040.

Then I ran gdb in xemacs and got the error. At the time it's asking me to
"Create a core file?..."  I went back to the terminal and did "gdb" -> "attach
6040" -> "bt" and got:

#0  0x774d000d in ntdll!DbgBreakPoint ()
   from /cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x7755f896 in ntdll!DbgUiRemoteBreakin ()
   from /cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x737f657a in ?? ()
#3  0x00000000 in ?? ()


Does this help?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #8 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
I guess GDB had different PID than 6040.  6040 was for xemacs, not for GDB.

But I do not know anything about MS-Windows and how GDB behaves there.
It had some problems unwinding MS-Windows system libraries (which do not use
DWARF) but that should be fixed in gdb 7.6.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING
                 CC|                            |palves at redhat dot com

--- Comment #9 from Pedro Alves <palves at redhat dot com> ---
> From cygwin terminal, I ran xemacs as a background process via "xemacs &"
> which gave me the PID 6040.

That's definitely not the PID you want.  Also, "bt" after attach will not show
the thread we need (Windows injects a thread in the process to stop it; that's
where that DbgBreakPoint comes from.)

Run gdb in xemacs until you get the error.  At the time it's asking you to
"Create a core file?...", look for the running _gdb_'s PID.  It's GDB you want
to attach to, not xemacs.  E.g., "ps -ef | grep gdb" in the cygwin shell may
work.  Then do "gdb -p PID" -> "thread apply all bt".

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[edderic at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #10 from edderic at gmail dot com ---
(In reply to Pedro Alves from comment #9)
> > From cygwin terminal, I ran xemacs as a background process via "xemacs &"
> > which gave me the PID 6040.
> 
> That's definitely not the PID you want.  Also, "bt" after attach will not
> show the thread we need (Windows injects a thread in the process to stop it;
> that's where that DbgBreakPoint comes from.)
> 
> Run gdb in xemacs until you get the error.  At the time it's asking you to
> "Create a core file?...", look for the running _gdb_'s PID.  It's GDB you
> want to attach to, not xemacs.  E.g., "ps -ef | grep gdb" in the cygwin
> shell may work.  Then do "gdb -p PID" -> "thread apply all bt".

First of all, thanks for all the help, Folks!

So I called Xemacs from Cygwin Terminal and ran gdb in Xemacs.

Then I did the following...



eu6pq@L1-JPS-228-T ~
$ ps -ef | grep gdb
   eu6pq    1932    4904 pty1     13:39:48 /usr/bin/gdb

eu6pq@L1-JPS-228-T ~
$ gdb -p 1932
GNU gdb (GDB) 7.6.50.20130508-cvs (cygwin-special)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Attaching to process 4164
[New Thread 4164.0x1304]
[New Thread 4164.0x158]
[New Thread 4164.0xab4]
Reading symbols from /usr/bin/gdb.exe...(no debugging symbols found)...done.
(gdb) thread apply all bt

Thread 3 (Thread 4164.0xab4):
#0  0x779a000d in ntdll!DbgBreakPoint () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x77a2f896 in ntdll!DbgUiRemoteBreakin () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x70e8e12f in ?? ()
#3  0x00000000 in ?? ()

Thread 2 (Thread 4164.0x158):
#0  0x779af8e5 in ntdll!ZwReadFile () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x779af8e5 in ntdll!ZwReadFile () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x76cbdd54 in ReadFile () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll
#3  0x00000098 in ?? ()
#4  0x00000000 in ?? ()

Thread 1 (Thread 4164.0x1304):
#0  0x779b013d in ntdll!ZwWaitForMultipleObjects () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x779b013d in ntdll!ZwWaitForMultipleObjects () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x76cc15e9 in WaitForMultipleObjectsEx () from
/cygdrive/c/Windows/syswow64/KERNELBASE.dll
#3  0x00000002 in ?? ()
#4  0x014ea418 in ?? ()
#5  0x75d11a2c in WaitForMultipleObjectsEx () from
/cygdrive/c/Windows/syswow64/kernel32.dll
#6  0x75d14220 in WaitForMultipleObjects () from
/cygdrive/c/Windows/syswow64/kernel32.dll
#7  0x61005ff0 in cygwait(void*, _LARGE_INTEGER*, unsigned int) () from
/usr/bin/cygwin1.dll
#8  0xffffffff in ?? ()
(gdb)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #11 from Pedro Alves <palves at redhat dot com> ---
Just to confirm:

Between:

> So I called Xemacs from Cygwin Terminal and ran gdb in Xemacs.

and:

> Then I did the following...

You got gdb to error out, right?  If you have, then I'm afraid the backtrace is
useless.  :-/

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[edderic at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #12 from edderic at gmail dot com ---
(In reply to Pedro Alves from comment #11)
> Just to confirm:
> 
> Between:
> 
> > So I called Xemacs from Cygwin Terminal and ran gdb in Xemacs.
> 
> and:
> 
> > Then I did the following...
> 
> You got gdb to error out, right?  If you have, then I'm afraid the backtrace
> is useless.  :-/

Yes. Running gdb in xemacs *automatically* causes the "Assertion '*pmy_chain ==
SENTINEL_CLEANUP' failed" error.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #13 from Tom Tromey <tromey at redhat dot com> ---
Another possibility is to start gdb in the shell using the same
arguments that XEmacs passes.  Perhaps that will still cause the
crash.  Then debugging is simpler: stick "gdb --args" in front to run
gdb on gdb.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[edderic at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #14 from edderic at gmail dot com ---
(In reply to Tom Tromey from comment #13)
> Another possibility is to start gdb in the shell using the same
> arguments that XEmacs passes.  Perhaps that will still cause the
> crash.  Then debugging is simpler: stick "gdb --args" in front to run
> gdb on gdb.

Could you clarify? Are you saying to do "M-x gdb gdb--args" in Xemacs?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #15 from Tom Tromey <tromey at redhat dot com> ---
When you run gdb in xemacs, xemacs should show you the arguments.
This may be --fullname or --annotate=2 or even -i=mi.

Once you see how it is invoking, go to the shell and type:

gdb --args gdb --fullname ... whatever else ...

This will work provided the crash happens early, as you said in
comment #11

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[palves at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #16 from Pedro Alves <palves at redhat dot com> ---
I just realized you're debugging a release build of GDB, most likely an
optimized build without debug info.  If you build a debug build of GDB from
sources ("-O0 -g"), chances are a backtrace on that error would be (more)
complete.  You'll need it to do the debugging Tom is suggesting too, anyway.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[edderic at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #17 from edderic at gmail dot com ---
(In reply to Pedro Alves from comment #16)
> I just realized you're debugging a release build of GDB, most likely an
> optimized build without debug info.  If you build a debug build of GDB from
> sources ("-O0 -g"), chances are a backtrace on that error would be (more)
> complete.  You'll need it to do the debugging Tom is suggesting too, anyway.

What does "-O0" do? I don't see in in gdb man page.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[tromey at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #18 from Tom Tromey <tromey at redhat dot com> ---
He means that you need to rebuild gdb, this time with debugging
symbols, so that you get a good stack trace.  -g and -O0 are compiler
options.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[edderic at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #19 from edderic at gmail dot com ---
(In reply to Tom Tromey from comment #18)
> He means that you need to rebuild gdb, this time with debugging
> symbols, so that you get a good stack trace.  -g and -O0 are compiler
> options.

Ok. How do I exactly do that? Do I need to find the source code for gdb and
recompile it with -g and -O0? Sorry, I am not as skilled as any of you yet ;)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[sergiodj at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

Sergio Durigan Junior <sergiodj at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sergiodj at redhat dot com

--- Comment #20 from Sergio Durigan Junior <sergiodj at redhat dot com> ---
(In reply to edderic from comment #19)
> Ok. How do I exactly do that? Do I need to find the source code for gdb and
> recompile it with -g and -O0? Sorry, I am not as skilled as any of you yet ;)

I am not experienced with Windows/Cygwin, but yes, he meant you need to get the
GDB source and compile it with -g and -O0.  It would be interesting if you
could build using the latest CVS version.  To get it, you can do a:

"cvs -d :pserver:anoncvs@sourceware.org:/cvs/src co gdb"

[Assuming CVS is installed on your system.]  It will checkout the source code
inside a directory called "src/".  Then, you can compile GDB:

$ cd src && mkdir mybuild && cd mybuild
$ ./configure CFLAGS='-g -O0' # check for missing deps here, install them
$ make

If everything works, you should have a GDB binary on the "gdb/" directory
(inside "mybuild/").  Then, you can try to reproduce the error with it, and get
a proper backtrace from it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[edderic at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #21 from edderic at gmail dot com ---
(In reply to Sergio Durigan Junior from comment #20)
> (In reply to edderic from comment #19)
> > Ok. How do I exactly do that? Do I need to find the source code for gdb and
> > recompile it with -g and -O0? Sorry, I am not as skilled as any of you yet ;)
> 
> I am not experienced with Windows/Cygwin, but yes, he meant you need to get
> the GDB source and compile it with -g and -O0.  It would be interesting if
> you could build using the latest CVS version.  To get it, you can do a:
> 
> "cvs -d :pserver:anoncvs@sourceware.org:/cvs/src co gdb"
> 
> [Assuming CVS is installed on your system.]  It will checkout the source
> code inside a directory called "src/".  Then, you can compile GDB:
> 
> $ cd src && mkdir mybuild && cd mybuild
> $ ./configure CFLAGS='-g -O0' # check for missing deps here, install them
> $ make
> 
> If everything works, you should have a GDB binary on the "gdb/" directory
> (inside "mybuild/").  Then, you can try to reproduce the error with it, and
> get a proper backtrace from it.

Thanks for the help, Sergio.

So I downloaded the files and the src folder was in the desktop. I did the
./configure CFLAGS='-g -O0' command when the current directory is .../src and I
got the following below.

The first dependency that configure can't find is "gnatbind". I tried searching
online for gnatbind source code or executable but I can't find it anywhere. I
also did "locate gnatbind" and "which gnatbind" and it is non-existent. Any
ideas where I can find it?


UR@L1-JPS-228-T /cygdrive/c/Users/UR/Desktop/src
$ ./configure CFLAGS='-g -O0'
checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking target system type... i686-pc-cygwin
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /usr/bin/sed
checking for gawk... gawk
checking to see if cat works as expected... yes
checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking whether g++ accepts -static-libstdc++ -static-libgcc... no
checking for gnatbind... no
checking for gnatmake... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1
$$f2
checking for objdir... .libs
checking for version 0.10 of ISL... no
checking for version 0.11 of ISL... no
checking for default BUILD_CONFIG...
checking for bison... no
checking for byacc... no
checking for yacc... no
checking for bison... no
checking for gm4... no
checking for gnum4... no
checking for m4... no
checking for flex... no
checking for lex... no
checking for flex... no
checking for makeinfo... makeinfo
checking for expect... no
checking for runtest... no
checking for ar... ar
checking for as... as
checking for dlltool... dlltool
checking for ld... (cached)
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld.exe
checking for lipo... no
checking for nm... nm
checking for ranlib... ranlib
checking for strip... strip
checking for windres... windres
checking for windmc... windmc
checking for objcopy... objcopy
checking for objdump... objdump
checking for readelf... readelf
checking for cc... cc
checking for c++... c++
checking for gcc... gcc
checking for gcj... no
checking for gfortran... gfortran
checking for gccgo... no
checking for ar... ar
checking for as... as
checking for dlltool... dlltool
checking for ld... ld
checking for lipo... no
checking for nm... nm
checking for objdump... objdump
checking for ranlib... ranlib
checking for readelf... readelf
checking for strip... strip
checking for windres... windres
checking for windmc... windmc
checking where to find the target ar... host tool
checking where to find the target as... host tool
checking where to find the target cc... host tool
checking where to find the target c++... host tool
checking where to find the target c++ for libstdc++... host tool
checking where to find the target dlltool... host tool
checking where to find the target gcc... host tool
checking where to find the target gcj... host tool
checking where to find the target gfortran... host tool
checking where to find the target gccgo... host tool
checking where to find the target ld... host tool
checking where to find the target lipo... host tool
checking where to find the target nm... host tool
checking where to find the target objdump... host tool
checking where to find the target ranlib... host tool
checking where to find the target readelf... host tool
checking where to find the target strip... host tool
checking where to find the target windres... host tool
checking where to find the target windmc... host tool
checking whether to enable maintainer-specific portions of Makefiles... no
configure: creating ./config.status
config.status: creating Makefile

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[edderic at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #22 from edderic at gmail dot com ---
Ok, I also tried to "configure" the GDB source code that is downloadable
through Cygwin and I was able to get the same results above.

I went through the Cygwin setup to look for dependencies, and I was able to
install some of them successfully (and I was unable to find others). The output
is below:


$ ./configure CFLAGS='-g -O0'
checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking target system type... i686-pc-cygwin
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /usr/bin/sed
checking for gawk... gawk
checking to see if cat works as expected... yes
checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking whether g++ accepts -static-libstdc++ -static-libgcc... no
checking for gnatbind... gnatbind
checking for gnatmake... gnatmake
checking whether compiler driver understands Ada... yes
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1
$$f2
checking for objdir... .libs
checking for version 0.10 of ISL... no
checking for version 0.11 of ISL... no
checking for default BUILD_CONFIG...
checking for bison... bison -y
checking for bison... bison
checking for gm4... no
checking for gnum4... no
checking for m4... m4
checking for flex... flex
checking for flex... flex
checking for makeinfo... makeinfo
checking for expect... expect
checking for runtest... no
checking for ar... ar
checking for as... as
checking for dlltool... dlltool
checking for ld... (cached)
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld.exe
checking for lipo... no
checking for nm... nm
checking for ranlib... ranlib
checking for strip... strip
checking for windres... windres
checking for windmc... windmc
checking for objcopy... objcopy
checking for objdump... objdump
checking for readelf... readelf
checking for cc... cc
checking for c++... c++
checking for gcc... gcc
checking for gcj... no
checking for gfortran... gfortran
checking for gccgo... no
checking for ar... ar
checking for as... as
checking for dlltool... dlltool
checking for ld... ld
checking for lipo... no
checking for nm... nm
checking for objdump... objdump
checking for ranlib... ranlib
checking for readelf... readelf
checking for strip... strip
checking for windres... windres
checking for windmc... windmc
checking where to find the target ar... host tool
checking where to find the target as... host tool
checking where to find the target cc... host tool
checking where to find the target c++... host tool
checking where to find the target c++ for libstdc++... host tool
checking where to find the target dlltool... host tool
checking where to find the target gcc... host tool
checking where to find the target gcj... host tool
checking where to find the target gfortran... host tool
checking where to find the target gccgo... host tool
checking where to find the target ld... host tool
checking where to find the target lipo... host tool
checking where to find the target nm... host tool
checking where to find the target objdump... host tool
checking where to find the target ranlib... host tool
checking where to find the target readelf... host tool
checking where to find the target strip... host tool
checking where to find the target windres... host tool
checking where to find the target windmc... host tool
checking whether to enable maintainer-specific portions of Makefiles... no
configure: creating ./config.status
config.status: creating Makefile

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[edderic at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #24 from edderic at gmail dot com ---
See attachment for make failure...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[edderic at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #23 from edderic at gmail dot com ---
Created attachment 7092
  --> http://sourceware.org/bugzilla/attachment.cgi?id=7092&action=edit
Text file showing make failure

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[kris at asc dot uk.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

Kris Thielemans <kris at asc dot uk.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kris at asc dot uk.com

--- Comment #25 from Kris Thielemans <kris at asc dot uk.com> ---
Hi
I can reproduce this easily with current (24/7/2013) cygwin which has gdb
version 7.6.50.20130508-cvs 
It appears when using the "-cd" argument to gdb (as used by xemacs gdb.el),
i.e.

$ gdb -cd . your_executable.exe

I've managed to get the gdb source from cygwin and compile it after

../gdb-7.6.50-2/configure CFLAGS="-g -O0" --disable-gdbtk
--with-system-readline

The error is then the same, and the backtrace is as below

$ gdb --args gdb  -cd .
~/devel/parapet/build/gcc/Debug/iterative/OSMAPOSL/OSMAPOSL.exe                
 Python Exception <type 'exceptions.ImportError'> No module named gdb:

warning:
Could not load the Python gdb module from `/usr/local/share/gdb/python'.
Limited Python support is available from the _gdb module.
Suggest passing --data-directory=/path/to/gdb/data-directory.

GNU gdb (GDB) 7.6.50.20130508-cvs (cygwin-special)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/src/build/gdb/gdb/gdb...done.
Setting up the environment for debugging gdb.
Breakpoint 1 at 0x61afad: file ../../../gdb-7.6.50-2/gdb/utils.c, line 842.
Breakpoint 2 at 0x45099a: file ../../../gdb-7.6.50-2/gdb/cli/cli-cmds.c, line
223.
Warning: /home/kris/../../../gdb-7.6.50-2/gdb/../libiberty: No such file or
directory.
Warning: /home/kris/../../../gdb-7.6.50-2/gdb/../bfd: No such file or
directory.
Warning: /home/kris/../../../gdb-7.6.50-2/gdb: No such file or directory.
(top-gdb) r
Starting program: /usr/src/build/gdb/gdb/gdb -cd .
/home/kris/devel/parapet/build/gcc/Debug/iterative/OSMAPOSL/OSMAPOSL.exe
[New Thread 18348.0x1e0]
During symbol reading, dll starting at 0x76b90000 not found..
[New Thread 18348.0x33d4]
[New Thread 18348.0x3e1c]
Python Exception <type 'exceptions.ImportError'> No module named gdb:

warning:
Could not load the Python gdb module from `/usr/local/share/gdb/python'.
Limited Python support is available from the _gdb module.
Suggest passing --data-directory=/path/to/gdb/data-directory.

GNU gdb (GDB) 7.6.50.20130508-cvs (cygwin-special)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...

Breakpoint 1,
During symbol reading, incomplete CFI data; unspecified registers (e.g., eax)
at 0x61afaa.
internal_error (file=0x755778 <sentinel_cleanup+64>
"../../../gdb-7.6.50-2/gdb/cleanups.c", line=264,
    string=0x755748 <sentinel_cleanup+16> "%s: Assertion `%s' failed.")
    at ../../../gdb-7.6.50-2/gdb/utils.c:842
842       va_start (ap, string);
(top-gdb) bt
#0  internal_error (file=0x755778 <sentinel_cleanup+64>
"../../../gdb-7.6.50-2/gdb/cleanups.c",
    line=264, string=0x755748 <sentinel_cleanup+16> "%s: Assertion `%s'
failed.")
    at ../../../gdb-7.6.50-2/gdb/utils.c:842
#1  0x004d07a4 in restore_my_cleanups (pmy_chain=0x70fd20 <cleanup_chain>,
chain=0x8003ae58)
    at ../../../gdb-7.6.50-2/gdb/cleanups.c:264
#2  0x004d07c7 in restore_cleanups (chain=0x8003ae58) at
../../../gdb-7.6.50-2/gdb/cleanups.c:273
#3  0x00534a5f in catcher_pop () at ../../../gdb-7.6.50-2/gdb/exceptions.c:121
#4  0x00534af4 in exceptions_state_mc (action=CATCH_ITER) at
../../../gdb-7.6.50-2/gdb/exceptions.c:149
#5  0x00534c89 in exceptions_state_mc_action_iter () at
../../../gdb-7.6.50-2/gdb/exceptions.c:210
#6  0x0053550f in catch_command_errors (command=0x450d58 <cd_command>,
arg=0x28fac08 ".", from_tty=0,
    mask=6) at ../../../gdb-7.6.50-2/gdb/exceptions.c:571
#7  0x0053824d in captured_main (data=0x28fab80) at
../../../gdb-7.6.50-2/gdb/main.c:924
#8  0x00535400 in catch_errors (func=0x537610 <captured_main>,
func_args=0x28fab80,
    errstring=0x76d6c0 <__PRETTY_FUNCTION__.12246+146> "", mask=6)
    at ../../../gdb-7.6.50-2/gdb/exceptions.c:546
#9  0x005386e2 in gdb_main (args=0x28fab80) at
../../../gdb-7.6.50-2/gdb/main.c:1064
#10 0x004011d4 in main (argc=4, argv=0x28fabbc) at
../../../gdb-7.6.50-2/gdb/gdb.c:34
(top-gdb)

This might point to a bug in cd_command.

I had a look at applying the patch from Keith Seitz 2013-05-22 used to fix a
similar assert, as mentioned by the OP. I didn't do this careful enough
probably, but it didn't solve the problem. This seems to make sense to me as
this patch is related to find_frame_funname, while here it is the command line
processing.

HTH

Kris

PS: I didn't try current CVS gdb. I have no idea if cygwin has special fixes
for gdb.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

Jan Kratochvil <jan.kratochvil at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ktietz at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[kris at asc dot uk.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

--- Comment #26 from Kris Thielemans <kris at asc dot uk.com> ---
Hi
I tried this now with  7.6.50.20130801-cvs. No problem there whatsoever, both
on cygwin and Ubuntu. So, something must have changed in CVS since the
cygwin-special fixing the problem. I guess this can be closed therefore

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[jan.kratochvil at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

Jan Kratochvil <jan.kratochvil at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |WORKSFORME

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/15650] xemacs gdb cleanups.c:264: internal-error: restore_my_cleanups: Assertion '*pmy_chain == SENTINEL_CLEANUP' failed

[kris at asc dot uk.com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15650

Kris Thielemans <kris at asc dot uk.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WORKSFORME                  |FIXED

--- Comment #27 from Kris Thielemans <kris at asc dot uk.com> ---
ah well. the problem disappeared with current cygwin (7.6.50.20130728-cvs) as
well. it seems that somebody is faster than me!

-- 
You are receiving this mail because:
You are on the CC list for the bug.