[Bf-committers] blender v275: why are pointer-keys in file no longer unique?

[Daniel Balster]

Hi Bastien,

checked it, fixed also my issue :-)

thanks,
  Daniel!

On Sun, Aug 9, 2015 at 10:16 PM, Bastien Montagne <montagne29 at wanadoo.fr>
wrote:

> Hi Daniel,
>
> No, it was not intended at all - trying to fix bad logic (and a crasher)
> in our mesh customdata writing code, I ended up created that even worse
> situation (which, for some exotic reason related to order of reading,
> did not affect Blender reading itself).
>
> This was bad for sure, and has been fixed since a few weeks now (see
> https://developer.blender.org/rBff3d535bc2a63092357533acbe7289556af956a0).
>
> Cheers,
> Bastien
>
> Le 09/08/2015 21:34, Daniel Balster a écrit :
> > Hi,
> >
> > I'm importing 3D data directly from .blend files for a few years now.
> Today
> > I found out that if a scene was saved with version 2.7.5 it is creating
> > non-unique block pointers:
> >
> > - the .blend consists of blocks, each of them has the "old pointer" from
> > the last session, and data is using these pointers as keys
> >
> > here's a small C code that lists all these pointers:
> >
> > // works only with le 64-bit blend files on le 64-bit machines
> > #include <stdio.h>
> > #include <sys/stat.h>
> > #include <sys/mman.h>
> > #include <fcntl.h>
> > typedef struct { char code[4]; int size; char *pointer; int index; int
> > count; } block;
> > int main(int argc, char **argv) {
> >    struct stat st;
> >    int fd=open(argv[1],O_RDONLY);
> >    if (fstat(fd, &st)) return 1;
> >    size_t size = st.st_size;
> >    void *addr = mmap(0, size, PROT_READ,MAP_FILE+MAP_PRIVATE, fd, 0);
> >    block *b = (block*)((char*)addr + 12);
> >    for (;;) {
> >      if (b->code[0]=='E' && b->code[1]=='N' && b->code[2]=='D' &&
> > b->code[3]=='B') break;
> >      printf("%p\n",b->pointer);
> >      b = (block*) (((char*)b) + sizeof(block) + b->size);
> >    }
> >    return 0;
> > }
> >
> > compile it as blenddump and use it like this:
> >
> > blenddump file.blend | sort | uniq -d
> >
> > and it will show you duplicate pointer keys.
> >
> > This behavior started with v275, if you load any older version and save
> it,
> > it will suddenly have these non-unique keys.
> >
> > The data blocks causing this are only the CustomDataLayer's
> >
> > so if you have a mesh with ldata, pdata, vdata, etc the back-reference to
> > another block should be impossible, but it's still working for blender.
> > Haven't checked why it's still working, just want to put this here.
> >
> > Any clues? Intended behavior? Could this cause problems?
> >
> > -daniel-
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>