DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082009-10-25T23:56:18ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Bug #1587 (Feedback): can't gdb across forkhttps://bugs.dragonflybsd.org/issues/15872009-10-25T23:56:18Zcorecode
<p>When the debugged process performs a fork(), gdb/ptrace won't notice and <br />will not be able to remove breakpoints in the new child. When the child <br />then hits a breakpoint, it will receive a SIGTRAP and dump core.</p>
<p>gdb needs to be aware of forks, so that it will be able to remove the <br />breakpoints in the child.</p>
<p>Test: gdb sh and break stalloc.</p> DragonFlyBSD - Bug #1584 (In Progress): can't use ssh from jail: debug1: read_passphrase: can't o...https://bugs.dragonflybsd.org/issues/15842009-10-23T17:28:21Zcorecode
<p>When running ssh from a jail, I get:</p>
<p>debug1: read_passphrase: can't open /dev/tty: Device busy</p>
<p>can also repeat this:</p>
<ol>
<li>cat `tty`<br />cat: /dev/pts/4: Device busy</li>
</ol>
<p>outside:<br />% cat `tty`<br />^C</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #1583 (In Progress): panic: assertion: cursor->trans->sync_lock_refs > 0 in ha...https://bugs.dragonflybsd.org/issues/15832009-10-23T01:46:46Zcorecode
<p>Happened when I started 8 mirror-stream at the same time.</p>
<p>(kgdb) bt<br />#0 _get_mycpu () at ./machine/thread.h:83<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: lib/libcr/sys/ cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/1">#1</a> dumpsys () at /usr/src/sys/kern/kern_shutdown.c:657<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: K&R -> ANSI cleanup status (Closed)" href="https://bugs.dragonflybsd.org/issues/2">#2</a> 0xc019ba89 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:378<br /><a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: freebsds pipe-reverse test fails on dfly (Closed)" href="https://bugs.dragonflybsd.org/issues/3">#3</a> 0xc019bdf5 in panic (fmt=0xc032b90c "assertion: %s in %s")<br /> at /usr/src/sys/kern/kern_shutdown.c:813<br /><a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: Rework of nrelease (Closed)" href="https://bugs.dragonflybsd.org/issues/4">#4</a> 0xc0299c7f in hammer_recover_cursor (cursor=0xe84826b4)<br /> at /usr/src/sys/vfs/hammer/hammer_cursor.c:591<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: sys/dev cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/5">#5</a> 0xc02a5139 in hammer_ioc_mirror_write (trans=0xe8482a50, <br />ip=0xea5ce6d0, mirror=0xe51a6f88)<br /> at /usr/src/sys/vfs/hammer/hammer_mirror.c:465<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: sys/emulation cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/6">#6</a> 0xc02a37b8 in hammer_ioctl (ip=0xea5ce6d0, com=3234097160, <br />data=0xe51a6f88 "", fflag=1,<br /> cred=0xc6787308) at /usr/src/sys/vfs/hammer/hammer_ioctl.c:142<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: /sys/boot cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/7">#7</a> 0xc02b65e4 in hammer_vop_ioctl (ap=0xe8482aac) at <br />/usr/src/sys/vfs/hammer/hammer_vnops.c:2305<br /><a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: make upgrade broken (Closed)" href="https://bugs.dragonflybsd.org/issues/8">#8</a> 0xc0203107 in vop_ioctl (ops=0xe4795b70, vp=0xea5f22e8, <br />command=3234097160,<br /> data=0xe51a6f88 "", fflag=1, cred=0xc6787308, msg=0xe8482cf0)<br /> at /usr/src/sys/kern/vfs_vopops.c:389<br /><a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: panic with HEAD (Closed)" href="https://bugs.dragonflybsd.org/issues/9">#9</a> 0xc0202b75 in vn_ioctl (fp=0xe4585910, com=3234097160, <br />data=0xe51a6f88 "", ucred=0xc6787308,<br /> msg=0xe8482cf0) at /usr/src/sys/kern/vfs_vnops.c:938<br /><a class="issue tracker-1 status-5 priority-5 priority-high3 closed" title="Bug: make buildworld broken (Closed)" href="https://bugs.dragonflybsd.org/issues/10">#10</a> 0xc01c3c1b in fo_ioctl (fd=3, com=3234097160,<br /> uspc_data=0xbfbff954 <Address 0xbfbff954 out of bounds>, map=0x0, <br />msg=0xe8482cf0)<br /> at /usr/src/sys/sys/file2.h:88<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: libstand cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/11">#11</a> mapped_ioctl (fd=3, com=3234097160, uspc_data=0xbfbff954 <Address <br />0xbfbff954 out of bounds>,<br /> map=0x0, msg=0xe8482cf0) at /usr/src/sys/kern/sys_generic.c:697<br /><a class="issue tracker-1 status-5 priority-3 priority-lowest closed" title="Bug: /sys/net cleanup (Closed)" href="https://bugs.dragonflybsd.org/issues/12">#12</a> 0xc01c3ccb in sys_ioctl (uap=0xe8482cf0) at <br />/usr/src/sys/kern/sys_generic.c:521<br /><a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Buildworld error/panic (Closed)" href="https://bugs.dragonflybsd.org/issues/13">#13</a> 0xc03088ea in syscall2 (frame=0xe8482d40) at <br />/usr/src/sys/platform/pc32/i386/trap.c:1339<br /><a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: zombie processes waiting for a lock, smth to worry about? (Closed)" href="https://bugs.dragonflybsd.org/issues/14">#14</a> 0xc02f3356 in Xint0x80_syscall () at <br />/usr/src/sys/platform/pc32/i386/exception.s:876</p>
<p>kernel+core nr. 13 on leaf:~corecode/crash</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #1556 (New): many processes stuck in "hmrrcm", system unusablehttps://bugs.dragonflybsd.org/issues/15562009-10-04T01:19:29Zcorecode
<p>On chlamydia I have many processes stuck in "hmrrcm", making the system <br />unusable - can't open new shells, etc. After a minute or two the <br />situation seems to improve again.</p> DragonFlyBSD - Bug #1547 (In Progress): disklabel64 automatic sizinghttps://bugs.dragonflybsd.org/issues/15472009-10-02T20:18:02Zcorecode
<p>disklabel64 is a prime example for unintuitive behavior:</p>
<ul>
<li>it requires an arbitrary 4KB aligment on sizes and offset</li>
<li>size aligments seem to be enforced directly, but offset alignments are <br />not. offsets just show up as "ILLEGAL" when re-editing the label. no <br />complaint before</li>
<li>automatic sizing using "*" does not work:</li>
</ul>
<p>d: * * HAMMER</p>
<p>but then:<br />partition d: size out of bounds (4825292800)</p>
<p>the size is completely off, roughly by a factor of 10(!)</p>
<p>I had to do:</p>
<p>d: 4 * HAMMER</p>
<p>and then re-edit to make it read</p>
<p>d: * 4712200 HAMMER</p>
<ul>
<li>there is no way to change the display block size</li>
<li>there is no way to specify sector counts or byte counts in size/offset</li>
</ul> DragonFlyBSD - Bug #1528 (In Progress): ktrace does not show proper return values for pipe(2)https://bugs.dragonflybsd.org/issues/15282009-09-24T15:58:42Zcorecode
<p>When ktracing a pipe syscall, the output is:</p>
<p>57705 a.out CALL pipe<br />57705 a.out RET pipe 3</p>
<p>However, the return value of pipe is 0, and the returned value for the <br />file descs is {3, 4}.</p> DragonFlyBSD - Bug #1527 (Closed): extremely bad USB/msdos performancehttps://bugs.dragonflybsd.org/issues/15272009-09-24T06:42:31Zcorecode
<p>The performance for writing to msdosfs on an ehci usb device is <br />pathetic. I'm getting ~500KB/sec, while other OS can do at least 6MB.</p>
<p>the rsync process is most of the time in "iowait", "biows", "biord".</p>
<p>vmstat:<br /> tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni <br />sy in id<br /> 8 680 60.86 56 3.33 0.00 0 0.00 10.00 2 0.02 3 0 <br />5 0 93<br /> 7 400 64.00 2 0.12 0.00 0 0.00 16.00 1 0.02 1 0 <br />5 0 94<br /> 10 415 64.00 2 0.12 0.00 0 0.00 0.00 0 0.00 3 0 <br />5 0 92<br /> 9 528 0.00 0 0.00 0.00 0 0.00 16.00 2 0.03 2 0 <br />3 0 95<br /> 9 541 64.00 4 0.25 0.00 0 0.00 16.00 86 1.34 2 0 <br />6 0 92<br /> 10 399 0.00 0 0.00 0.00 0 0.00 16.00 138 2.16 4 0 <br />6 0 90<br /> 8 546 64.00 2 0.12 0.00 0 0.00 16.00 4 0.06 7 0 <br />8 0 85<br /> 7 509 37.75 89 3.28 0.00 0 0.00 15.68 37 0.57 3 0 <br />8 0 89<br /> 10 545 0.00 0 0.00 0.00 0 0.00 16.00 131 2.05 3 0 <br />8 0 89<br /> 1 104 4.00 1 0.00 0.00 0 0.00 16.00 40 0.62 5 0 <br />7 0 87<br /> 2 226 48.00 86 4.03 0.00 0 0.00 14.29 7 0.10 4 0 <br />6 0 90<br /> 102 100 64.00 2 0.12 0.00 0 0.00 16.00 110 1.72 2 0 <br />5 0 93<br /> 126 102 64.00 2 0.12 0.00 0 0.00 16.00 37 0.58 3 0 <br />6 0 91<br /> 72 103 64.00 1 0.06 0.00 0 0.00 13.29 124 1.61 0 0 <br />4 0 95<br /> 42 98 64.00 1 0.06 0.00 0 0.00 0.00 0 0.00 1 0 <br />3 0 96<br /> 176 225 45.40 86 3.81 0.00 0 0.00 16.00 2 0.03 4 0 <br />6 0 90<br /> 136 104 19.43 84 1.59 0.00 0 0.00 16.00 11 0.17 7 0 <br />8 0 85<br /> 70 121 0.00 0 0.00 0.00 0 0.00 16.00 26 0.41 1 0 <br />10 0 89<br /> 26 100 64.00 5 0.31 0.00 0 0.00 16.00 140 2.19 2 0 <br />5 0 93<br /> 2 219 56.79 91 5.05 0.00 0 0.00 15.79 58 0.89 3 0 <br />6 0 91</p> DragonFlyBSD - Bug #1475 (In Progress): kernel blocks with low memory and syscons setting a high ...https://bugs.dragonflybsd.org/issues/14752009-09-01T03:06:17Zcorecode
<p>I just booted with hw.physmem=32m. I have my allscreens_flags set to -h <br />4700 MODE_279. When processing the allscreens_flags in rc.d, the system <br />blocks (not hangs) while booting, ^T says "no controlling terminal". No <br />mode change occured. Same happened with 48m, just with a mode change, <br />so I suspect it to have worked for one screen but then not for another.</p> DragonFlyBSD - Bug #1474 (New): ithread 1 unexpectedly rescheduledhttps://bugs.dragonflybsd.org/issues/14742009-09-01T03:02:23Zcorecode
<p>Just had a hang during high swap activity. I kept pressing ^T to see <br />what is happening, suddenly the kernel said "ithread 1 unexpectedly <br />rescheduled". SMP 4-way system.</p> DragonFlyBSD - Bug #1469 (In Progress): Hammer history security concernhttps://bugs.dragonflybsd.org/issues/14692009-08-28T17:59:03Zcorecode
<p>Hammer history mounts allow access to deleted files.</p>
<p>This can be an issue if you realized that this data should not have been <br />available in the first place.</p>
<p>An alternate scenario is that group membership changed, and you don't <br />want the new group members to have access to past data.</p>
<p>I think we should address this in some sort in the release. One way is <br />to only allow the owner to access the snapshot, and ignore group/other <br />permissions on snapshots. This is probably very inconvenient, <br />especially for root owned system directories.</p>
<p>Another way would be to somehow combine current and past owner/flags, <br />but this is probably hard to reason about.</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #1442 (New): blocking SIGSEGV and triggering a segment violation produces an a...https://bugs.dragonflybsd.org/issues/14422009-07-28T20:05:09Zcorecode
<p>If a process blocks (or ignores?) SIGSEGV (or SIGFPE, SIGILL, SIGBUS, etc.) and<br />then triggers the associated signal without having a handler installed, the<br />process/thread will be stuck on the triggering instruction without any hope.</p>
<p>I think the kernel should detect such a situation (i.e. trap leading to<br />blocked/ignored signal without handler) and should kill the process.</p> DragonFlyBSD - Bug #1440 (New): ptrace/gdb doesn't work after process blocks SIGTRAPhttps://bugs.dragonflybsd.org/issues/14402009-07-28T20:01:56Zcorecode
<p>If a process blocks SIGTRAP, an attached debugger will not be able to break<br />again (same is true for SIGINT, for instance).</p>
<p>We should change the behavior so that the debugger will be able to see this<br />signal, or to change how a ptrace'd process gets suspended on trap exceptions.</p> DragonFlyBSD - Bug #745 (Closed): the evil interrupt stats monster is still around!https://bugs.dragonflybsd.org/issues/7452007-07-27T05:45:02Zcorecode
<p>hey,</p>
<p>while doing the pkgsrc bulk build, I get weird numbers in top. I am pretty sure this has something to do with the multitude of shell scripts being used as wrappers in pkgsrc. command execution is also slower than I'd expect (for example wrapper execution).</p>
<p>load averages: 8.38, 7.96, 5.53 up 0+03:48:32 22:34:35<br />151 processes: 151 running<br />CPU0 states: 13.7% user, 0.0% nice, 27.5% system, 0.0% interrupt, 58.8% idle<br />CPU1 states: 21.4% user, 0.0% nice, 28.3% system, 0.0% interrupt, 50.4% idle<br />CPU2 states: 22.1% user, 0.0% nice, 22.9% system, 0.0% interrupt, 55.0% idle<br />CPU3 states: 34.7% user, 0.0% nice, 11.1% system, 42.0% interrupt, 12.2% idle<br />Mem: 71M Active, 509M Inact, 268M Wired, 199M Buf, 2665M Free<br />Swap:</p>
<pre><code>PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND<br />36155 root 227 0 3060K 2736K wait 2 0:00 36.82% 8.15% bmake<br />37456 root 229 0 828K 704K RUN 1 0:00 16.14% 2.93% sh<br />37677 root 197 0 1576K 1216K wait 2 0:00 14.53% 2.64% bmake<br />40985 root 182 0 824K 700K RUN 3 0:00 40.00% 1.95% sh<br />41135 root 193 0 820K 696K wait 1 0:00 39.00% 1.90% sh<br />37807 root 172 0 828K 704K wait 0 0:00 9.69% 1.76% sh<br />37310 root 157 0 792K 668K wait 0 0:00 9.15% 1.66% sh<br />37961 root 210 0 1600K 1240K wait 0 0:00 10.85% 1.51% bmake<br />40898 root 157 0 784K 660K wait 2 0:00 30.00% 1.46% sh<br />37563 root 227 0 1464K 1104K wait 1 0:00 5.92% 1.07% bmake<br />37391 root 168 0 788K 664K wait 0 0:00 4.84% 0.88% sh<br />37316 root 162 0 1668K 1296K wait 0 0:00 4.57% 0.83% bmake<br />40213 root 182 0 1216K 1092K wait 1 0:00 16.00% 0.78% sh<br />39756 root 229 0 824K 700K wait 0 0:00 2.05% 0.20% sh<br />23163 root 163 0 1444K 1084K wait 2 0:00 0.26% 0.15% bmake<br /> 679 corecode 152 0 5948K 3116K select 0 0:05 0.00% 0.00% sshd<br />87928 corecode 152 0 2340K 1632K RUN 0 0:03 0.00% 0.00% top<br /> 5266 root 152 0 6548K 6120K kqread 0 0:02 0.00% 0.00% pbulk-build<br /> 2346 root 152 0 2384K 2052K select 2 0:01 0.00% 0.00% screen-4.0.3<br /> 672 corecode 152 0 5948K 3112K select 2 0:01 0.00% 0.00% sshd<br /> 6357 corecode 152 0 5948K 3124K select 0 0:00 0.00% 0.00% sshd<br />83074 root 157 0 3236K 2908K wait 0 0:00 0.00% 0.00% bmake<br />61160 root 152 0 2340K 1632K CPU0 0 0:00 0.00% 0.00% top<br />84410 root 192 0 3152K 2828K wait 0 0:00 0.00% 0.00% bmake<br />60999 root 157 0 3388K 3072K wait 1 0:00 0.00% 0.00% bmake</code></pre>
<p>that's what systat -vm tells:</p>
<pre><code>11 users Load 9.22 8.60 6.50 Jul 26 22:39</code></pre>
<p>Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER<br /> Tot Share Tot Share Free in out in out<br />Act 28560 5260 67456 9252 2717488 count<br />All 880132 8524 1793432 13480 pages<br /> 13651 zfod Interrupts<br />Proc:r p d s w Csw Trp Sys Int Sof Flt 16467 cow 556 total<br /> 10 45 727964259438586 475 6638986 284684 wire 429 clk<br /> 70624 act 13 uhci0<br />21.6%Sys 12.8%Intr 30.8%User 0.0%Nice 34.8%Idl 524220 inact 69 atapci1
| | | | | | | | | | cache 11 em0<br />===========++++++>>>>>>>>>>>>>>>> 2717552 free ata0<br /> daefr irq19<br />Namei Name-cache Dir-cache 21446 prcfr 34 irq21<br /> Calls hits % hits % react<br /> 81740 79364 97 189 0 pdwake<br /> pdpgs<br />Disks ad4 ad6 acd0 cd0 pass0 md0 intrn<br />KB/t 0.00 36.23 0.00 0.00 0.00 0.00 204096 buf<br />tps 0 34 0 0 0 0 1533 dirtybuf<br />MB/s 0.00 1.21 0.00 0.00 0.00 0.00 231015 desiredvnodes<br />% busy 0 3 0 0 0 0 81881 numvnodes<br /> 1602 freevnodes</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #742 (In Progress): umount problems with multiple mountshttps://bugs.dragonflybsd.org/issues/7422007-07-27T02:46:01Zcorecode
<p>hey,</p>
<p>yes, my fault, but:</p>
<pre>
%mount
/dev/ad6s1a on / (ufs, local, soft-updates)
/dev/ad6s1b on /pbulk (ufs, local, soft-updates)
/ on /pbulk/clients/labospc67_1/root (null, local, read-only)
/pbulk/clients/labospc67_1/var on /pbulk/clients/labospc67_1/root/var (null, local)
/pbulk/clients/labospc67_1/tmp on /pbulk/clients/labospc67_1/root/tmp (null, local)
/pbulk/clients/labospc67_1/dev on /pbulk/clients/labospc67_1/root/dev (null, local)
/ on /pbulk/clients/labospc67_1/root (null, local, read-only)
%umount labospc67_1/root
umount: unmount of /pbulk/clients/labospc67_1/root failed: Device busy
%umount /pbulk/clients/labospc67_1/root/var
umount: unmount of /pbulk/clients/labospc67_1/root/var failed: Invalid argument
</pre>
<p>something is wrong here. i guess I can't umount the "upper" root mount, because it takes the "lower" root mount first. dito for the subdirs.</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #731 (New): system freeze on "slice too large"https://bugs.dragonflybsd.org/issues/7312007-07-15T20:11:05Zcorecode
<p>hey,</p>
<p>i've now had twice a nasty freeze (kind of) with something like this (hand transcribed):</p>
<p><code>dscheck(#ad/0x20021): slice too large 2/2</code><br />..</p>
<p>then vinum tells me that it put "build" down and continues:</p>
<p>fatal: build.p0.s0 read error, offset 33831591936 for 4096 bytes<br />build.p0.s0: user buffer offset 10209280000 for 4096 bytes</p>
<p>(more slice too large follow)</p>
<p>then, the namecache does</p>
<p>blocked on 0xd4fb7b58 "corecode"</p>
<p>and repeats it every 30 seconds or so. system is unoperable at this point.</p>
<p>breaking to the debugger works, but dumpsys does not work:</p>
<pre>
dumping to dev #ad/0x20023, blockno 2130432
dump failed, reason: area improper
</pre>
<p>i'm running:<br /><pre>
DragonFly sweatshorts.home.corecode.ath.cx 1.9.0-DEVELOPMENT DragonFly 1.9.0-DEVELOPMENT #14: Sun Jun 17 11:03:58 CEST 2007 corecode@sweatshorts.home.corecode.ath.cx:/usr/build/obj/usr/build/src/sys/SWEATSHORTS i386
</pre></p>
<p>i've attached relevant outputs.</p>
<p>thanks,<br /> simon</p>