Sicherheit im LAN > Computer & Software

Yosemite Backup 8.5 SP2 crashing badly on SLES10 SP3 / OES2 SP2


After Upgrading a Novell SLES10 Server from SP2 to SP3 everything worked just nice, only Yosemite Server Backup 8.5 from Barracudaware went havoc. Fist it corrupted its database causing a disk utilization that rendered the server unusable. With a new (clean) library the backup daemon crashed repeatedly after several hours, again destroying its library.

Linux event log showed the following error:

ytlinsdr: *** glibc detected *** /usr/local/yosemite/yosemitebackup/v8.50-sp2/lin/x86_64/ytlinsdr: double free or corruption (!prev): ...

This indicates that there is a memory allocation problem in ytlinsdr that causes it to be killed.

This issue could surface in other linux distributions as well. Barracudaware support indicates that there are no plans to fix this bug, it may also show up in Yosemite Backup 8.7


Even BarracudaWare Yosemite Server Backup 8.8.01 doesn't work with SLES10 SP3.
I installed a fresh demo version today with an empty database, created a backup job and started a backup. This job ran about an hour at maximum LTO speed then suddenly crashed. Error message is different now, something like:
kernel: Call Trace: <ffffffff80167420>{__alloc_pages+796} <ffffffff80182814>{kmem_getpages+106}
kernel:        <ffffffff80183bf9>{fallback_alloc+275} <ffffffff8018411b>{__kmalloc+179}
kernel:        <ffffffff8016cb97>{kzalloc+9} <ffffffff801a6d45>{getxattr+137}
kernel:        <ffffffff8019668d>{link_path_walk+218} <ffffffff801fe82b>{__up_write+205}
kernel:        <ffffffff801a6e6b>{sys_lgetxattr+75} <ffffffff801fe82b>{__up_write+205}
kernel:        <ffffffff8017320d>{sys_munmap+81} <ffffffff8010ae16>{system_call+126}

That's too bad since the 8.8 user inferface is looking really good again after the horrible 8.x intermezzo.

So be warned when upgrading to SLES10 SP3!


[0] Message Index

Go to full version