DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Packages and Ports

OpenBSD Packages and Ports Installation and upgrading of packages and ports on OpenBSD.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 19th March 2013
thirdm thirdm is offline
Package Pilot
 
Join Date: May 2009
Posts: 203
Thanked 3 Times in 3 Posts
Default confirm possible bug in cwm or emacs

Hi, if someone is running cwm and emacs 24.2 linked to gtk3, can you do me a favour? I think I'm seeing an error where cwm inappropriately sends the emacs window to the back in the window stacking order in response to a certain X event. If you could try the following and tell me if emacs stays on top, I'd greatly appreciate it:

1. open an emacs window (frame in emacs parlance).
2. open at least one other (non-emacs) window in the same cwm group.
3. bring the emacs window to the front so it overlaps the other window.
4. evaluate the following expression in emacs's *scratch* buffer:
(raise-frame)
You can evaluate this form by pressing ctrl-x ctrl-e with the cursor after the right parenthesis.

Does the emacs window stay on top or go to the back? How old is your emacs port and cwm build? I don't imagine it matters, but what architecture do you use (I'm seeing this on macppc)?

If anyone has an emacs flavour not linked to gtk3, I'd be curious if you see the problem too.
Reply With Quote
  #2   (View Single Post)  
Old 19th March 2013
daemonfowl daemonfowl is offline
bsdstudent
 
Join Date: Jan 2012
Location: DaemonLand
Posts: 834
Thanked 0 Times in 0 Posts
Default

Hi thirdm.
You are right ! emacs window gets overlapped

Code:
kern.version=OpenBSD 5.3 (GENERIC) #36: Tue Mar 12 20:52:24 MDT 2013
    deraadt@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC
emacs version : 24.2.1

Such a bug doesn't occur on i386 (OpenBSD current + emacs.24.2.1)

Last edited by daemonfowl; 22nd March 2013 at 05:28 AM. Reason: +details
Reply With Quote
  #3   (View Single Post)  
Old 20th March 2013
thirdm thirdm is offline
Package Pilot
 
Join Date: May 2009
Posts: 203
Thanked 3 Times in 3 Posts
Default

Thanks for trying it out. I'll try to figure this out over the coming days (and weeks?), see if I can come up with a patch.
Reply With Quote
  #4   (View Single Post)  
Old 2nd April 2013
thirdm thirdm is offline
Package Pilot
 
Join Date: May 2009
Posts: 203
Thanked 3 Times in 3 Posts
Default

An update on this:

Over the weekend I tried building cwm with debugging information. Surprisingly when I installed that the problem went away. I then stripped the cwm binary and tried again. Still no problem. Now I'm thinking one of the following happened:

1. I didn't have the source I thought I did, so my debugging rebuild reverted to source before the bug appeared or after it was fixed.
1.1. The bug only appeared in the snapshot I'd taken (I gather snapshots sometimes include code, for testing purposes, that never reaches cvs) and doesn't exist in current. I thought that I had built from current after taking a february snapshot, but it's possible I missed a step in building/installing xenocara and really had the snapshot binary of cwm still. (Unfortunately I forgot to back up the old binary before overwriting it with the debugging one -- I'll try getting the snapshot binary out of the dist. tarball later if I can)
2. My environment is inconsistent or out of sync in some way and the bug is really only an artifact of that. (not consistent with you reproducing it)
3. There's a subtle timing issue involved that makes it an intermittent bug. Maybe running with debugging symbols skewed things to where it didn't happen. (not consistent with stripping having it still missing or that you could reproduce it)

I'm going away for a few days, but I'll try to dig into this next week to see what I did and if I can still reproduce the bug.

I'm kind of puzzled here but at least it going away when I rebuilt (only) cwm points to it (if it's real) being a cwm issue more likely than something wrong with emacs or Xorg in general.
Reply With Quote
  #5   (View Single Post)  
Old 15th April 2013
thirdm thirdm is offline
Package Pilot
 
Join Date: May 2009
Posts: 203
Thanked 3 Times in 3 Posts
Default

Well, I looked at this again tonight and it gets weirder. It's not a source sync or incorrect xenocara install problem. It really is the addition of the debugging symbols that made the bug go away.

One thing I don't understand. If I have a cwm binary built with CFLAGS=-g and INSTALL_STRIP='' there seems nothing I can pass to the strip command to turn that binary back into the equivalent of one built without debugging info in the first place. I guess I should read the gcc docs about -g or look at the files using readelf or something, but does anyone have any quick hints about that part of it?

Well, I see there are other options than plain -g that gcc accepts (Options for Debugging Your Program or GCC). I'll try some of these maybe, see if I can get enough debugging to step through cwm but not enough to turn off the bug. Do you think anything there's likely to be useful?
Reply With Quote
  #6   (View Single Post)  
Old 5th May 2013
thirdm thirdm is offline
Package Pilot
 
Join Date: May 2009
Posts: 203
Thanked 3 Times in 3 Posts
Default

So this was a bug in cwm (which means this thread ideally ought not to have been reclassified as a port issue -- I guess as BSD fans we suppose emacs more likely to be at fault than a window manager in OpenBSD's base?). The likely reason for it going away when I first tried adding debug info was that it involved an uninitialized variable. What value the variable has can depend on things like architecture and binary layout. I'd say this also would explain why it was architecture dependent for you, daemonfowl.

As an aside, I wasn't going about adding debug info the right way. There is a make variable documented in share/mk/bsd.README named DEBUG which will set the CFLAGS and STRIP variables appropriately. I haven't gone back to see exactly what I did wrong with CFLAGS yet, but once I used...
Code:
make DEBUG=-g
...in the cwm source directory I got a cwm binary that I could step through and that still showed the buggy behaviour. Maybe I treated CFLAGS as an environment variable as opposed to a make variable? I'm mixed up right now about whether environment variables become make variables. I'll play around with that and read a bit more when I'm on that machine again.

Someone who may or may not be the owner of the forum handle thirdm posted a report and a patch here: http://marc.info/?l=openbsd-bugs&m=136751371922327&w=2

If anyone wants more explanation, let me know.
Reply With Quote
  #7   (View Single Post)  
Old 5th May 2013
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,149
Thanked 182 Times in 149 Posts
Default

make(1) will use environment variables but as you noticed there are subtle differences.

A simple Makefile:
Code:
test:
.ifdef CFLAGS 
        @echo Yes, CFLAGS has been defined: $${CFLAGS}
        env | grep CFLAGS 
.else
        @echo No, CFLAGS has not been defined !!!
.endif


test2:
.ifdef MONKEY  
        @echo Yes, MONKEY has been defined: $${MONKEY}
        env | grep MONKEY 
.else
        @echo No, MONKEY has not been defined !!!
.endif
Some tests with the test2 target:
Code:
$  env MONKEY=gorilla make test2

Yes, MONKEY has been defined: gorilla
env | grep MONKEY 
MONKEY=gorilla

$  make test2 MONKEY=chimp

Yes, MONKEY has been defined: chimp
env | grep MONKEY 
MONKEY=chimp
MAKEFLAGS= MONKEY=chimp

$ make test2
No, MONKEY has not been defined !!!
Note that when setting the environment variable with the env(1) utility, the MAKEFLAGS= MONKEY=chimp does not show in the environment output.

With CFLAGS:
Code:
$ env CFLAGS=-02 make test
Yes, CFLAGS has been defined: -02
env | grep CFLAGS 
CFLAGS=-02

$  make CFLAGS=-O2 test

Yes, CFLAGS has been defined: -O2
env | grep CFLAGS 
MAKEFLAGS= CFLAGS=-O2
CFLAGS=-O2

$ make test

Yes, CFLAGS has been defined:
env | grep CFLAGS 
*** Error 1 in /home/adriaan/TEST (Makefile:4 'test')
According to make(1) CFLAGS is an internal make variable. This explains the output of $ make test where it has been defined but apparently does not have a value assigned yet.

It seems that only when you specify the variable like # make CFLAGS=xxx it is seen as a one of the MAKEFLAGS.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #8   (View Single Post)  
Old 6th May 2013
thirdm thirdm is offline
Package Pilot
 
Join Date: May 2009
Posts: 203
Thanked 3 Times in 3 Posts
Default

Thanks for experimenting for me. That's an interesting clue. According to make's man page, the env variable MAKEFLAGS (and the make variables .MAKEFLAGS and MFLAGS) is set to include anything passed as command line arguments.

But how to apply this knowledge to understand what I might have done to temporarily lose the bug? I still have the binaries so can compare them with readelf:

normal cwm image with no debugging
<hr>
Size: 68K
Entry point address: 0x1802110
Start of section headers: 68416 (bytes into file)
Number of section headers: 30
Section header string table index: 29

cwm image with bug "disappeared" by mucking with CFLAGS and STRIP in unknown way.
<hr>
Size: 92K
Entry point address: 0x18021a0
Start of section headers: 92448 (bytes into file)
Number of section headers: 30
Section header string table index: 29
Symbol table '.dynsym' contains 170 entries:
Extra .dynsym symbols: tolower, ispunct, isspace, bzero

cwm image from make DEBUG=-g (shows problem and has debugging info)
<hr>
Size: 288K
Entry point address: 0x1802110
Start of section headers: 250252 (bytes into file)
Number of section headers: 41
Section header string table index: 38

I know what I did for sure now because I can reproduce this. I set
CFLAGS=-g and STRIP= (nothing) using export. Then I did make clean, make, and make install in the cwm directory.

It would appear that what I did was to turn off optimization. I guess those extra symbols were
things that gcc was able to throw away somehow, perhaps by inlining internal definitions. Another difference doing things the right way is that -g also gets passed to the linking call to gcc (it doesn't setting CFLAGS in the environment -- perhaps your MAKEFLAGS point comes into play here). Not sure what effect that has, if any.

Code:
# make -p | grep CFLAGS
CFLAGS           = -O2 ${PIPE} ${DEBUG} -Wall ${COPTS} $(COPTS)
COMPILE.c        = ${CC} ${CFLAGS} ${CPPFLAGS} -c
CONFIGURE_ENV    = PKG_CONFIG_LIBDIR="$(PKG_CONFIG_LIBDIR)"  CONFIG_SITE=$(CONFIG_SITE)  CFLAGS="$(CFLAGS:C/ *$//)"  MAKE="${MAKE}"
CXXFLAGS         = ${CFLAGS} ${CXXOPTS}
LINK.c           = ${CC} ${CFLAGS} ${CPPFLAGS} ${LDFLAGS}
        @files="${.ALLSRC:M*.s} ${.ALLSRC:M*.S}";  if [ "$$files" != " " ]; then  echo mkdep -a ${MKDEP} ${CFLAGS:M-[ID]*} ${CPPFLAGS} ${AINC} $$files; mkdep -a ${MKDEP} ${CFLAGS:M-[ID]*} ${CPPFLAGS} ${AINC} $$files;  fi
        @files="${.ALLSRC:M*.c}";  if [ "$$files" != "" ]; then  echo mkdep -a ${MKDEP} ${CFLAGS:M-[ID]*} ${CPPFLAGS} $$files;  mkdep -a ${MKDEP} ${CFLAGS:M-[ID]*} ${CPPFLAGS} $$files;  fi
# make DEBUG=-g -p | grep CFLAGS
CFLAGS           = -O2 ${PIPE} ${DEBUG} -Wall ${COPTS} $(COPTS)
COMPILE.c        = ${CC} ${CFLAGS} ${CPPFLAGS} -c
CONFIGURE_ENV    = PKG_CONFIG_LIBDIR="$(PKG_CONFIG_LIBDIR)"  CONFIG_SITE=$(CONFIG_SITE)  CFLAGS="$(CFLAGS:C/ *$//)"  MAKE="${MAKE}"
CXXFLAGS         = ${CFLAGS} ${CXXOPTS}
LINK.c           = ${CC} ${CFLAGS} ${CPPFLAGS} ${LDFLAGS}
        @files="${.ALLSRC:M*.s} ${.ALLSRC:M*.S}";  if [ "$$files" != " " ]; then  echo mkdep -a ${MKDEP} ${CFLAGS:M-[ID]*} ${CPPFLAGS} ${AINC} $$files; mkdep -a ${MKDEP} ${CFLAGS:M-[ID]*} ${CPPFLAGS} ${AINC} $$files;  fi
        @files="${.ALLSRC:M*.c}";  if [ "$$files" != "" ]; then  echo mkdep -a ${MKDEP} ${CFLAGS:M-[ID]*} ${CPPFLAGS} $$files;  mkdep -a ${MKDEP} ${CFLAGS:M-[ID]*} ${CPPFLAGS} $$files;  fi
# env CFLAGS=-g make -p | grep CFLAGS
COMPILE.c        = ${CC} ${CFLAGS} ${CPPFLAGS} -c
CONFIGURE_ENV    = PKG_CONFIG_LIBDIR="$(PKG_CONFIG_LIBDIR)"  CONFIG_SITE=$(CONFIG_SITE)  CFLAGS="$(CFLAGS:C/ *$//)"  MAKE="${MAKE}"
CXXFLAGS         = ${CFLAGS} ${CXXOPTS}
LINK.c           = ${CC} ${CFLAGS} ${CPPFLAGS} ${LDFLAGS}
CFLAGS           = -g -Wall ${COPTS} $(COPTS)
        @files="${.ALLSRC:M*.s} ${.ALLSRC:M*.S}";  if [ "$$files" != " " ]; then  echo mkdep -a ${MKDEP} ${CFLAGS:M-[ID]*} ${CPPFLAGS} ${AINC} $$files; mkdep -a ${MKDEP} ${CFLAGS:M-[ID]*} ${CPPFLAGS} ${AINC} $$files;  fi
        @files="${.ALLSRC:M*.c}";  if [ "$$files" != "" ]; then  echo mkdep -a ${MKDEP} ${CFLAGS:M-[ID]*} ${CPPFLAGS} $$files;  mkdep -a ${MKDEP} ${CFLAGS:M-[ID]*} ${CPPFLAGS} $$files;  fi
Reply With Quote
  #9   (View Single Post)  
Old 13th June 2013
thirdm thirdm is offline
Package Pilot
 
Join Date: May 2009
Posts: 203
Thanked 3 Times in 3 Posts
Default

This issue is fixed now, btw:

http://www.openbsd.org/cgi-bin/cvswe...1=1.83;r2=1.84
Reply With Quote
Old 27th July 2013
daemonfowl daemonfowl is offline
bsdstudent
 
Join Date: Jan 2012
Location: DaemonLand
Posts: 834
Thanked 0 Times in 0 Posts
Default

Hi thirdm !
Good work
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Emacs on OpenBSD on DEC VAX? haziz OpenBSD Packages and Ports 2 6th February 2013 10:24 PM
carefull confirm on using linux_base-fc8 Click to flag this post cuongvt FreeBSD General 2 8th May 2009 01:57 AM
Emacs nox11 unixbsd FreeBSD Ports and Packages 2 18th March 2009 02:17 PM
C/C++ Syntax highlighting in emacs rex FreeBSD General 1 12th October 2008 03:21 AM
Emacs without X? clevershark FreeBSD Ports and Packages 3 21st May 2008 05:02 PM


All times are GMT. The time now is 01:48 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick