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

[Bastien Montagne]

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
>