** Description changed:
regcomp fails to compile the regular expression "^ " with memory error
- if malloc(0) returns NULL. That's valid malloc behavior, compare
- malloc(3).
+ if malloc(0) returns NULL. That's valid malloc behavior, compare the man
+ page malloc(3).
I had a little trouble
** Attachment added: "program exhibiting bug (compile with -ldl)"
https://bugs.launchpad.net/bugs/998256/+attachment/3141970/+files/test.c
** Description changed:
regcomp fails to compile the regular expression "^ " with memory error
if malloc(0) returns NULL. That's valid malloc behavior,
Public bug reported:
regcomp fails to compile the regular expression "^ " with memory error
if malloc(0) returns NULL. That's valid malloc behavior, compare
malloc(3).
I had a little trouble debugging, but I believe the problem lies with
posix/regex_internal.c:re_node_set_alloc being called with
I may be mistaken, but the way I read the code, the "ENCODING" field
that is set using locale.getpreferredencoding as mentioned above only
affects the filename encoding (option "--fs-encoding").
On the other hand, eyeD3 seems to be quite limited regarding tags that
are not encoded with the default
Hello Colin,
> I expect at this point we shall mark this as "Won't Fix" for
> Hardy (since we are so close to the final release) but keep it open
> for
> Hardy + 1.
no problem at all if you do that. Thanks for all your work. I realize
this kind of thing is difficult to track down.
I'm sorry
I've now run fsck.hfs (an i386 binary):
$ ./fsck.hfsplus -d /dev/sdc1
** /dev/sdc1
** Checking HFS Plus volume.
** Detected a case-sensitive catalog.
** Checking Extents Overflow file.
** Checking Catalog file.
Invalid sibling link
(4, 8646)
** Rebuilding Catalog B-tree.
hfs_UNswap_BTNode: inv
> sudo dd if=/dev/sdX of=/dev/null
That works without error. Slightly under 20MB/s in case that's of
interest.
Interestingly, Linux mounts the device (complaining it wasn't cleanly
unmounted.) That might have been the case all along -- I'm not sure I
tried accessing it from Linux after the
Hello,
thanks for looking into this.
On Apr 7, 2008, at 13:40, Colin King wrote:
> 1. Did the running of rdiff-backup trigger the reported Oops and
> cause the broken filesystem?
> 2. Or was the oops caused later when you tried to do rdiff-backup
> on an already broken filesytem?
The oops wa
attaching relevant kern.log
** Attachment added: "kern.log.0"
http://launchpadlibrarian.net/12944209/kern.log.0
--
hfsplus oops, corrupted file system
https://bugs.launchpad.net/bugs/202595
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubu
requested attachments (let's see if this works via mail)
** Attachment added: "dmesg.log"
http://launchpadlibrarian.net/12944124/dmesg.log
** Attachment added: "lspci-vvnn.log"
http://launchpadlibrarian.net/12944125/lspci-vvnn.log
** Attachment added: "uname-a.log"
http://launchpadlibr
** Attachment added: "Dependencies.txt"
http://launchpadlibrarian.net/12687853/Dependencies.txt
--
hfsplus oops, corrupted file system
https://bugs.launchpad.net/bugs/202595
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-
Public bug reported:
Filesystem on a USB disk, journaling disabled, mounted read-write.
rdiff-backup was trying to clean up after a previously aborted backup.
The file system is now broken, Mac OS' Disk Utility failed to repair the
file system. It reported an "invalid sibling link", then tried
"re
I can confirm the problem. I've had awk scripts fail mysteriously due to
this bug on amd64. The current upstream release (3.1.6) has this fixed.
To be honest, I'm surprised this hasn't broken all kinds of stuff on my
system -- is awk not widely used for configuration, etc?
--
match operator brok
(If it is inappropriate for me to change status, feel free to revert.)
** Changed in: gawk (Ubuntu)
Status: New => Confirmed
--
match operator broken on amd64
https://bugs.launchpad.net/bugs/127850
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bu
And running the Ubuntu supplied 2.6.22-12-generic, the problem doesn't
occur.
--
After today's update to devmapper, system does not boot successfully
https://bugs.launchpad.net/bugs/144735
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubu
I can confirm this: For me, the boot doesn't fail because I don't have
any lvm-ed partition automounted (other than root), but manually
mounting partitions fails ("too many levels of symbolic links"), and
/dev/mapper is full of symlinks like above.
I should note that I'm running a custom self-comp
Fixed here, too. Though automatically causing update-initramfs to run
would have been nice.
--
Segfaults during boot (from mount)
https://bugs.launchpad.net/bugs/131961
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bug
I can confirm that this is busybox. I get segfaults when calling
'busybox mount -o move ...' for both /usr/lib/initramfs-
tools/bin/busybox and /bin/busybox (from the plain busybox package as
well as busybox-static).
** Changed in: busybox (Ubuntu)
Sourcepackagename: initramfs-tools => busybox
--
I should note that I have root on lvm also, but I don't have any further
problems. I don't have any other filesystems mounted automatically,
though.
Also, /var/crash doesn't seem to contain anything relevant (kvm, gnome-
panel_sensors-applet, apport-gtk).
--
segfault when booting 2.6.22-9-generi
Public bug reported:
Binary package hint: initramfs-tools
After upgrading to gutsy, I see segmentation faults during boot-up.
>From what I've been able to find out by scrolling back the console
when booting in recovery mode, these occurs when the script
/scripts/init-bottom is executed. That's wh
20 matches
Mail list logo