unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Ok, somebody give me a clue.
@ 2005-02-28 12:02 David Kastrup
  2005-02-28 14:06 ` Kim F. Storm
  0 siblings, 1 reply; 6+ messages in thread
From: David Kastrup @ 2005-02-28 12:02 UTC (permalink / raw)



For debugging purposes, I have been using the following:

struct trbuf { void* pc; int value; } trbuf[256];
unsigned char trptr;
#define RECORD_INPUT do { __label__ woozle; \
  woozle: trbuf[trptr++] = (struct trbuf)				\
			    { &&woozle, interrupt_input_blocked}; } while(0)

And then whereever I change interrupt_input_blocked, I also call
RECORD_INPUT.  This causes Emacs to crash in unrelated spaces.  I have
crosschecked the compiled code, and it does the correct thing: no data
type overflow problems or something.

So it is obvious that the problem is elsewhere, likely that the data
structures I use above confuse the garbage collector.  What kind of
data structures are allowed, and how can I hide data structures that
would confuse it from the garbarge collector?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Ok, somebody give me a clue.
  2005-02-28 12:02 Ok, somebody give me a clue David Kastrup
@ 2005-02-28 14:06 ` Kim F. Storm
  2005-02-28 14:48   ` Andreas Schwab
  2005-02-28 15:55   ` David Kastrup
  0 siblings, 2 replies; 6+ messages in thread
From: Kim F. Storm @ 2005-02-28 14:06 UTC (permalink / raw)
  Cc: emacs-devel

David Kastrup <dak@gnu.org> writes:

> For debugging purposes, I have been using the following:
>
> struct trbuf { void* pc; int value; } trbuf[256];
> unsigned char trptr;
> #define RECORD_INPUT do { __label__ woozle; \
>   woozle: trbuf[trptr++] = (struct trbuf)				\

Does [trptr++%256] give better results ?

> 			    { &&woozle, interrupt_input_blocked}; } while(0)
>
> And then whereever I change interrupt_input_blocked, I also call
> RECORD_INPUT.  This causes Emacs to crash in unrelated spaces.  I have
> crosschecked the compiled code, and it does the correct thing: no data
> type overflow problems or something.
>
> So it is obvious that the problem is elsewhere, likely that the data
> structures I use above confuse the garbage collector.  What kind of
> data structures are allowed, and how can I hide data structures that
> would confuse it from the garbarge collector?
>
> -- 
> David Kastrup, Kriemhildstr. 15, 44793 Bochum
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
>

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Ok, somebody give me a clue.
  2005-02-28 14:06 ` Kim F. Storm
@ 2005-02-28 14:48   ` Andreas Schwab
  2005-02-28 16:20     ` David Kastrup
  2005-02-28 15:55   ` David Kastrup
  1 sibling, 1 reply; 6+ messages in thread
From: Andreas Schwab @ 2005-02-28 14:48 UTC (permalink / raw)
  Cc: emacs-devel

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
>
>> For debugging purposes, I have been using the following:
>>
>> struct trbuf { void* pc; int value; } trbuf[256];
>> unsigned char trptr;
>> #define RECORD_INPUT do { __label__ woozle; \
>>   woozle: trbuf[trptr++] = (struct trbuf)				\
>
> Does [trptr++%256] give better results ?

trptr is unsigned char, so won't ever be bigger than 255.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Ok, somebody give me a clue.
  2005-02-28 14:06 ` Kim F. Storm
  2005-02-28 14:48   ` Andreas Schwab
@ 2005-02-28 15:55   ` David Kastrup
  2005-03-02 11:23     ` Richard Stallman
  1 sibling, 1 reply; 6+ messages in thread
From: David Kastrup @ 2005-02-28 15:55 UTC (permalink / raw)
  Cc: emacs-devel

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
>
>> For debugging purposes, I have been using the following:
>>
>> struct trbuf { void* pc; int value; } trbuf[256];
>> unsigned char trptr;
>> #define RECORD_INPUT do { __label__ woozle; \
>>   woozle: trbuf[trptr++] = (struct trbuf)				\
>
> Does [trptr++%256] give better results ?

No, I already did that.  I also increased the amount of pure storage
size since obviously that macro gets compiled in a lot.  No go.  I had
a version temporarily where I initialized the data, causing it to end
up in the .data segment, seemingly a nono.  But I have checked that it
is now correctly in .bss.

I also tried replacing the code by something without the
constructor-style task.  No luck.

>> And then whereever I change interrupt_input_blocked, I also call
>> RECORD_INPUT.  This causes Emacs to crash in unrelated spaces.  I
>> have crosschecked the compiled code, and it does the correct thing:
>> no data type overflow problems or something.

Bah.  I have now tracked this down.  The following causes crashes
already with SIGSEGV at some unrelated place.

#define RECORD_INPUT do { __label__ woozle; woozle: ; } while (0)

If I instead use

#define RECORD_INPUT do { ; } while (0)

it works.  So either gcc is broken with regard to local labels, or it
produces something from them which confuses the dumper.

Does anybody have a good clue whether this is just to be considered an
Emacs internal problem?

I'll probably get at the current address by some other means as well,
but it might be something which one ought to report, unless it is just
our dumper.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Ok, somebody give me a clue.
  2005-02-28 14:48   ` Andreas Schwab
@ 2005-02-28 16:20     ` David Kastrup
  0 siblings, 0 replies; 6+ messages in thread
From: David Kastrup @ 2005-02-28 16:20 UTC (permalink / raw)
  Cc: emacs-devel, Kim F. Storm

Andreas Schwab <schwab@suse.de> writes:

> storm@cua.dk (Kim F. Storm) writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> For debugging purposes, I have been using the following:
>>>
>>> struct trbuf { void* pc; int value; } trbuf[256];
>>> unsigned char trptr;
>>> #define RECORD_INPUT do { __label__ woozle; \
>>>   woozle: trbuf[trptr++] = (struct trbuf)				\
>>
>> Does [trptr++%256] give better results ?
>
> trptr is unsigned char, so won't ever be bigger than 255.

Type promotion can lead to strange effects.  While trptr++ seems like
a safe bet, I would not trust ++trptr...

Anyway, this apparently is a compiler or a dumper problem with the
local label.  I have to get at the current address with a different
method, probably inline assembly.  Pity.

Or construct a non-local label name from __LINE__.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Ok, somebody give me a clue.
  2005-02-28 15:55   ` David Kastrup
@ 2005-03-02 11:23     ` Richard Stallman
  0 siblings, 0 replies; 6+ messages in thread
From: Richard Stallman @ 2005-03-02 11:23 UTC (permalink / raw)
  Cc: emacs-devel, storm

    If I instead use

    #define RECORD_INPUT do { ; } while (0)

    it works.  So either gcc is broken with regard to local labels, or it
    produces something from them which confuses the dumper.

The way to debug a problem like that is by looking at the assembler
code and seeing if it corresponds correctly to the source.

It is important to do this, because if GCC has a bug, we need to fix
it.  However, is there a later GCC you could try?  Maybe the bug is
fixed already.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2005-03-02 11:23 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-02-28 12:02 Ok, somebody give me a clue David Kastrup
2005-02-28 14:06 ` Kim F. Storm
2005-02-28 14:48   ` Andreas Schwab
2005-02-28 16:20     ` David Kastrup
2005-02-28 15:55   ` David Kastrup
2005-03-02 11:23     ` Richard Stallman

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).