Daily blurbs Jun. 2005

Plans

daily blurbs


28 Jun 2005 (Tue)

08:38:05 # Life dpep_template_hardcoded is not accepting '-d' options, thus without a template file, it's not using the description. It will need to change.

22 Jun 2005 (Wed)

08:08:44 # Life debootstrap debugging. It feels rather annoying to have to debug something someone has rewritten and never worked; to debug something that is rewritten and never worked, I need to guess at the intention of how it was to be implemented. /usr/sbin/debootstrap --variant=buildd sid . http://ring.asahi-net.or.jp/archives/linux/debian/debian. I've tracked it down to a line that is giving me an error where it shoulnd't be, but no idea yet on how to fix it.

08:47:14 # Life dpatch-edit-patch debugging. There are so many features that I didn't know about, and their existence restricts what can be done. It would be really nice to deprecate everything that seems unworthwhile. Having a system-wide configuration file for dpatch being able to specify a stamp-dir is a little over-featured. Also, stamp-dir really needs to be configured per-source, not per-system; and why not per-Debian? (as in all Debian dpatch-using packages agree on debian/patched/).

21 Jun 2005 (Tue)

08:44:25 # Life I've implemented dpatch-edit-patch testsuite. There are a few bugs in the implementation of current dpatch-edit-patch, and I'd like to approach the problem in a one-by-one approach. In my opinion, it's a tool that is widely used, and should be in a maintenance mode.

20 Jun 2005 (Mon)

08:17:52 # Life debootstrap seems to be unable to debootstrap sid with variant buildd. It just emits a message 'E: Couldn't find these debs: 0'

21:04:27 # Life Debugging debootstrap a bit more, I found a bit more info. I am guessing that it's obtaining the list of every single package in Debian while it's searching for Build-Essential packages. Sigh...

19 Jun 2005 (Sun)

10:23:57 # Life Played a bit with dpatch. I've added a testsuite for dpatch-edit-patch, since the documentation and code was a bit different from reality. There are obscure features that seem to be untested, and I think it will really benefit well from a regression test.

20:56:28 # Life I've felt an urge to check out what kind of memory handling C programs were using. I've created a test program that loops around and malloc/frees different memory sizes. To my surprise it was freeing back some of the malloc'd regions to the OS. However, since it's seeing different address for smaller mallocs, I am suspecting that it's not freeing smaller mallocs. This behavior agrees with how glibc source is written, and probably the intention. Nice.

/*BINFMTC:
 */
#include <stdio.h>
#include <stdlib.h>

main()
{
  int i;
  while (1) 
    {
      for (i=1; ; i<<=1)
	{
	  void*ptr;
	  ptr=malloc(i);
	  if (!ptr) break;
	  printf ("%i %p\n", i, ptr);
	  free(ptr);
	}
    }
}
	
1 0x804a008
2 0x804a008
4 0x804a008
8 0x804a008
16 0x804a018
32 0x804a030
64 0x804a058
128 0x804a0a0
256 0x804a008
512 0x804a008
1024 0x804a008
2048 0x804a008
4096 0x804a008
8192 0x804a008
16384 0x804a008
32768 0x804a008
65536 0x804a008
131072 0x804a008
262144 0xb7f49008
524288 0xb7f09008
1048576 0xb7e89008
2097152 0xb7d89008
4194304 0xb7b89008
8388608 0xb7789008
16777216 0xb6f89008
33554432 0xb5f89008
67108864 0xb3f89008
134217728 0xaff89008
268435456 0xa7f89008
536870912 0x97f89008
1073741824 0x77f89008

	  [snip]

1 0xb7e00480
2 0xb7e00480
4 0xb7e00480
8 0xb7e00480
16 0xb7e00490
32 0xb7e004a8
64 0xb7e004d0
128 0xb7e00518
256 0xb7e00480
512 0xb7e00480
1024 0xb7e00480
2048 0xb7e00480
4096 0xb7e00480
8192 0xb7e00480
16384 0xb7e00480
32768 0xb7e00480
65536 0xb7e00480
131072 0xb7e00480
262144 0xb7f49008
524288 0xb7f09008
1048576 0xb7cff008
2097152 0xb7bff008
4194304 0xb79ff008
8388608 0xb75ff008
16777216 0xb6dff008
33554432 0xb5dff008
67108864 0xb3dff008
134217728 0xafdff008
268435456 0xa7dff008
536870912 0x97dff008
1073741824 0x77dff008
	

Then I thought I'd like to make sure address space is mapped as I expect it to be. I've ran the program inside gdb and stopped it in middle of a glibc function, and took a backtrace, and compared with how the kernel thinks about it.

	
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x4515fb36 in munmap () from /lib/tls/i686/cmov/libc.so.6
#2  0x450fcd3c in malloc_set_state () from /lib/tls/i686/cmov/libc.so.6
#3  0x08048446 in main ()

$ cat /proc/6905/maps
08048000-08049000 r-xp 00000000 00:0d 9350       /tmp/a.out
08049000-0804a000 rw-p 00000000 00:0d 9350       /tmp/a.out
0804a000-0806b000 rw-p 0804a000 00:00 0          [heap]
45072000-45088000 r-xp 00000000 03:03 1929540    /lib/ld-2.3.2.so
45088000-45089000 rw-p 00015000 03:03 1929540    /lib/ld-2.3.2.so
4508b000-451b5000 r-xp 00000000 03:03 1929543    /lib/tls/i686/cmov/libc-2.3.2.so
451b5000-451be000 rw-p 00129000 03:03 1929543    /lib/tls/i686/cmov/libc-2.3.2.so
451be000-451c0000 rw-p 451be000 00:00 0
b7e00000-b7e21000 rw-p b7e00000 00:00 0
b7e21000-b7f00000 ---p b7e21000 00:00 0
b7f24000-b7f25000 rw-p b7f24000 00:00 0
b7f36000-b7f38000 rw-p b7f36000 00:00 0
bfb23000-bfb38000 rw-p bfb23000 00:00 0          [stack]
ffffe000-fffff000 ---p 00000000 00:00 0          [vdso]
	

21:07:51 # Life At CodeFestJapan 2005, akr implemented a ruby script redirect-process which redirects the output of an already-running process. I wanted to try and reimplement it with shell, and here is a one-liner. The stdout of the process of which PID is specified on PARAM= is output as the stdout. PARAM=12519 gdb -batch -n -x <( echo -e "attach $PARAM\nprint dup2(open(\"/proc/$$/fd/1\", 1), 1)" )

16 Jun 2005 (Thu)

22:15:12 # Life Somebody in Japan made a mascot character for Ubuntu in accordance to the Japanese Anime tradition, and created a wallpaper. I wonder what Debu-tan will look like; if Ubuntu-tan is like this.

12 Jun 2005 (Sun)

09:09:20 # Life Last night we had the 6th Tokyo area Debian study meeting. kmuto talked about Debian installer, and eto talked about dsys and update-alternatives. It's nice to hear hackers talk about their toy projects. There's always something new to hear.

18:08:41 # Life Debugging on pbuilder and other things that have been pending. Bug triage. Humph, not too bad a weekend. Having done a Debain study meeting puts me so motivated to get bugs fixed.

7 Jun 2005 (Tue)

06:58:14 # Life Gees, just as I when I woke up, I've seen the 'debian-announce: Debian GNU/Linux 3.1 released' headline flashing by. Great work folks! I find it impressive that it actually happened today.

5 Jun 2005 (Sun)

17:25:06 # Life Apparently, I've only been sending my revocation certificate by mail, and not uploaded to any of the keyservers; I've sent it out to the public keyservers now.

4 Jun 2005 (Sat)

02:14:24 # Life binfmtc now supports pascal and fortran. release 0.5.

15:20:38 # Life Result of Code Fest Japan 2005. After the 24 hours of intensive hacking, I'm taking pbuilder in a better shape than it was before. I've hacked testsuite support into pbuilder, and reasonably confident that it's starting to work. Guys here have discussed about possibility of getting debconf in Japan a possibility, and although the financials look uneasy, it could be a reality.

3 Jun 2005 (Fri)

08:53:22 # Life I will be attending CodeFestJapan 2005 today. It's going to start from 17:00 JST today and 17:00 JST tomorrow, a 24-hour hackathon. I'm planning on processing my backlogs on Debian work and getting things normal.

22:52:31 # Life Considering cost for debconf if it is held in Japan. Roughly, we're looking at 150 people, 10 days. This leads to around Y 20,000,000. Which feels rather difficult.

1 Jun 2005 (Wed)

08:44:39 # Life This weekend I will be attending CodeFestJapan 2005, which is an 24-hour endurance hacking event. It will start at 5pm, and I don't think I will really be able to stay up another 24 hours starting from that, but that's that. Hoping to get much hacking done.


Junichi Uekawa

$Id: 200506.html.en,v 1.24 2005/06/29 23:33:54 dancer Exp $