(Commands like reopen need to go to cont...@bugs.debian.org to work and the bug number needs to be given. See http://www.debian.org/Bugs - but I'm not re-opening the bug as this is not a bug in Debian AFAICT.)
On Sat, 29 Oct 2011 18:13:09 +0300 anatoly techtonik <techto...@gmail.com> wrote: > > I'm fairly sure it's not actually a bug in the source code of the Perl > > scripts themselves, so that approach won't get far. I see no reason to > > think this is a problem within svn-buildpackage itself, it is something > > to do with your VM configuration. > > That's not helpful. Perl executes ok. Other perl scripts also execute > ok. So the problem in the way Perk executed this particular script. The problem *appears* as a result of using this package, that's the best that can be demonstrated so far. No evidence that the package is the cause of the bug. (You are trying to pin the effect on the wrong cause.) The output below shows that there are low level memory and/or library linkage problems on this VM. Chances are high that if you installed a wider range of software on this VM you would find other packages demonstrating the same problem. It sounds like something in your low level setup is causing programs to end up accessing memory outside of the normal behaviour. Which programs will show the effect is entirely unpredictable - this time it's svn-buildpackage but there is nothing about svn-bp which is actually causing the memory corruption, it is simply the only package you've run so far which has revealed the underlying fault in your VM. > Maybe in the way Perl imports external modules. Think about it - you > should know. Perhaps the problem is in some binary extension or svn > bindings. I don't have experience with that. No evidence of that and the only evidence is solely under your control. There's nothing I can do about that. My advice? Ditch the current VM and recreate it from scratch. Something is definitely wrong in the low level config of this VM. Trash it. (That's why people use VM in the first place, after all.) > >> > Also try creating a Wheezy chroot and testing in that. > >> > >> Oh no. That's too hardcore. I don't want to pollute this VM more than > >> necessary. > > > > debootstrap wheezy dir/ > > chroot dir/ > > I am running Squeeze, not Wheezy. Is it ok? debootstrap carries scripts to cope with the release after the stable release, so yes, debootstrap in stable can always generate a bootstrap based on the testing release which follows it. > > It's not hard. Something had to call that to create the VM in the > > first place. It's how Debian Installer creates the installation. > > The machine was created with Xen. No, xen just provided the top level interface. Something installed the actual Debian packages and that is probably debootstrap because debootstrap is explicitly designed to be able to create Debian systems on most POSIX systems. Xen then provides another layer on top of the "chroot /dir" command to operate the VM. > Will it create other dirs like > pbuilder does somewhere in /var (or /usr)? I'd really like to keep > this machine clean of any extra stuff. This "machine" is demonstrating low level memory corruption issues. That is no basis for retaining it of trying to keep it clean. debootstrap will put the system under the current working directory so that you can just clean it up afterwards. HOWEVER, there seems little point doing that on this system because the VM itself is bust and a different chroot will still suffer memory corruption. It might show up with different packages but it will still be there. Create a debootstrap chroot on another machine and test svn-buildpackage there, maybe in a completely fresh VM but if that shows problems as well then on a completely different physical machine. You can create a Squeeze or Wheezy Debian system on another machine, build your package in that and copy the package to the VM. There is absolutely no need to build the package in the VM itself, especially if you want to keep the VM "clean". > > (yet you're expecting to use svn-buildpackage to build Debian packages > > to use on presumably other Debian machines?) > > I need to a stable version 0.6 of Bitten (which is trac-bitten) that > was not released yet in Debian. I can't build it on other machine, > because latest Python policy (not new version of package) requires > versions of packages like buildhelper that are absent on previous > versions. You are trying to backport a package which has never been packaged properly for Debian. svn-buildpackage is not the solution there. You'd have to learn Debian packaging properly and ask advice from http://mentors.debian.net I cannot help you with that task but there are others in Debian who can. mentors is the place for that assistance. > > I think you are blaming the wrong package - just because one package > > shows the error does not mean that the bug actually lies in that > > package. I suspect a problem in the VM itself and it's the kind of > > problem that will show up if you switch to using something else. i.e. > > it is likely to be a persistent problem with that one VM. > > I was about to say that there are no problems with VM, because even > `dmesg`... and then I checked dmesg and found this: > > [7288028.138482] svn-buildpackag[8557] trap invalid opcode > ip:7fefad14a8b0 sp:7fffd51ad528 error:0 in > ld-2.11.2.so[7fefad137000+1e000] Right. Low level memory corruption in your version of libc / dynamic linker / possibly a kernel interface. Buggy VM. Most certainly NOT a bug in svn-buildpackage, it is a bug somewhere in your VM setup. > [7349043.341234] perl[28518] trap invalid opcode ip:7fe39e8858b0 > sp:7fffbdab65b8 error:0 in ld-2.11.2.so[7fe39e872000+1e000] > [7349052.444836] perl[28521] trap invalid opcode ip:7f3309e358b0 > sp:7fffdb81bea8 error:0 in ld-2.11.2.so[7f3309e22000+1e000] > [7349068.116843] perl[28523] trap invalid opcode ip:7fa5e15248b0 > sp:7fff7dac6118 error:0 in ld-2.11.2.so[7fa5e1511000+1e000] Same. Not a bug in perl, a bug in your VM. > > If you haven't got time to investigate a problem that only you can > > produce, I see no point keeping this bug open because there is nothing > > we can do to fix it without you doing the work. Closing. > > Don't get me wrong. I have time to investigate the problem, but I > don't have time to learn the ways how to do this. What I expect from > you is to guide me. My guidance is limited to svn-bp, I only use VM very rarely and I come across memory corruptions like the ones seen in your dmesg snippet *only* when some compiled program gets linked against the wrong version of it's libraries or tries to access a library interface which has changed since the program was compiled. This is clearly not a bug in svn-buildpackage. I see no evidence that it's even a bug in any package within Debian. I *have* seen these issues when a VM has suffered corruption or misconfiguration. Google for "illegal instruction" and fix your VM. That's the limit of what I can offer. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
pgpEeE0avkRX9.pgp
Description: PGP signature
