Setting attribute to vertex sequence leads to failed assertion

[krlmlr]

Describe the bug

A specific usage pattern leads to a failed assertion in the C core.

To reproduce

options(conflicts.policy = list(warn = FALSE))
library(igraph)

gg <- make_ring(3, directed = TRUE)
V(gg)$id <- V(gg)
subgraph(gg, 1)
#> Error in induced_subgraph(graph, vids): At core/core/vector.pmt:483 : Assertion failed: v->stor_begin != NULL. This is an unexpected igraph error; please report this as a bug, along with the steps to reproduce it.
#> Please restart your R session to avoid crashes or other surprising behavior.

^{Created on 2023-05-21 with reprex v2.0.2}

Version information

• R/igraph version: 342586e
• R version: 4.3.0
• Operating system: macOS

[krlmlr]

Introduced in efc8bec.

[krlmlr]

This particular commit has been added to trigger the creation of the native igraph object. Maybe we need to be more careful with what we allow as attributes. Do we really need to support vertex/edge sequences as attributes?

[krlmlr]

CRAN igraph

options(conflicts.policy = list(warn = FALSE))
library(igraph)

gg <- make_ring(2, directed = TRUE)
V(gg)$id <- V(gg)
dput(gg)
#> structure(list(2, TRUE, c(0, 1), c(1, 0), c(0, 1), c(1, 0), c(0, 
#> 1, 2), c(0, 1, 2), list(c(1, 0, 1), list(name = "Ring graph", 
#>     mutual = FALSE, circular = TRUE), list(id = structure(1:2, class = "igraph.vs", is_all = TRUE, env = <weak reference>, graph = "17d54ab3-1bea-4723-8d5f-2e86ada40fe5")), 
#>     list()), <environment>), class = "igraph")
dput(as.list(unclass(gg)[[10]]))
#> list(me = structure(list(2, TRUE, c(0, 1), c(1, 0), c(0, 1), 
#>     c(1, 0), c(0, 1, 2), c(0, 1, 2), list(c(1, 0, 1), list(name = "Ring graph", 
#>         mutual = FALSE, circular = TRUE), list(), list()), <environment>), class = "igraph"), 
#>     myid = "17d54ab3-1bea-4723-8d5f-2e86ada40fe5")

^{Created on 2023-05-21 with reprex v2.0.2}

dev igraph

options(conflicts.policy = list(warn = FALSE))
library(igraph)

gg <- make_ring(2, directed = TRUE)
V(gg)$id <- V(gg)
dput(gg)
#> structure(list(2, TRUE, c(0, 1), c(1, 0), NULL, NULL, NULL, NULL, 
#>     list(c(1, 0, 1), list(name = "Ring graph", mutual = FALSE, 
#>         circular = TRUE), list(id = structure(1:2, class = "igraph.vs", is_all = TRUE, env = <weak reference>, graph = "a59b2801-46a9-4a00-a77b-53c364c25ac5")), 
#>         list()), <environment>), class = "igraph")
dput(as.list(unclass(gg)[[10]]))
#> list(me = structure(list(2, TRUE, c(0, 1), c(1, 0), NULL, NULL, 
#>     NULL, NULL, list(c(1, 0, 1), list(name = "Ring graph", mutual = FALSE, 
#>         circular = TRUE), list(), list()), <environment>), class = "igraph"), 
#>     igraph = <pointer: 0x600000ac81e0>, myid = "a59b2801-46a9-4a00-a77b-53c364c25ac5")

^{Created on 2023-05-21 with reprex v2.0.2}

[krlmlr]

This is getting way too complicated. Do we even need to support sequences as vertex/edge attributes? Perhaps it's worth doing a revdepcheck with just that change on top of v1.4.2 .

[szhorvat]

Do you have a clear understanding of how that null pointer arises, and if yes, can you please share it? (BTW an ASan-enabled test would make this much clearer as fatal errors cause the printing of a stack trace.)

The fix you propose is for the symptom, but it's good to be aware of the underlying cause ...

[szhorvat]

Do we even need to support sequences as vertex/edge attributes?

Theoretically, there's some benefit, as one might want to maintain a mapping between the vertex (or edges) of two graphs, e.g. after vertex deletion or subsetting. This is a convenient way to do it. Of course, using plain vertex or edge IDs would also achieve the same.

[szhorvat]

ASan output:

subgraph(gg, 1)
    #0 0x109b3b475 in __sanitizer_print_stack_trace+0x35 (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x53475) (BuildId: 7b794d8c5f0d346faaffee92f0e796262400000010000000000a0a00000e0a00)
    #1 0x1182cf7c8 in R_igraph_fatal_handler rinterface_extra.c:2446
    #2 0x117f1c221 in igraph_fatal error.c:368
    #3 0x117f62652 in igraph_vector_size vector.pmt:483
    #4 0x1182c8781 in R_igraph_attribute_permute_edges_diff rinterface_extra.c:1215
    #5 0x1182c8a0d in R_igraph_attribute_permute_edges rinterface_extra.c:1257
    #6 0x1181de099 in igraph_i_induced_subgraph_map subgraph.c:250
    #7 0x1181dcc2f in igraph_induced_subgraph subgraph.c:364
    #8 0x1182a0702 in R_igraph_induced_subgraph rinterface.c:1506
    #9 0x1087c85a7 in R_doDotCall dotcode.c:874
    #10 0x1087d503a in do_dotcall dotcode.c:1551
    #11 0x1088629d3 in Rf_eval eval.c:1120
    #12 0x1088b1c69 in do_set eval.c:3250
    #13 0x1088625f9 in Rf_eval eval.c:1092
    #14 0x1088b09f7 in do_begin eval.c:2798
    #15 0x1088625f9 in Rf_eval eval.c:1092
    #16 0x1088a7b20 in R_execClosure eval.c
    #17 0x1088931ef in Rf_applyClosure eval.c:2113
    #18 0x108862af7 in Rf_eval eval.c:1140
    #19 0x1088b09f7 in do_begin eval.c:2798
    #20 0x1088625f9 in Rf_eval eval.c:1092
    #21 0x1088a7b20 in R_execClosure eval.c
    #22 0x1088931ef in Rf_applyClosure eval.c:2113
    #23 0x108862af7 in Rf_eval eval.c:1140
    #24 0x108937b88 in Rf_ReplIteration main.c:262
    #25 0x10893a99e in run_Rmainloop main.c:314
    #26 0x10893aa92 in Rf_mainloop main.c:1215
    #27 0x10865c805 in main Rmain.c:29
    #28 0x7fff5dd5d3d4 in start+0x0 (libdyld.dylib:x86_64+0x163d4) (BuildId: 002418ccad113d10865b015591d24e6c320000002000000001000000000e0a00)

Error in induced_subgraph(graph, vids) : 
  At core/core/vector.pmt:483 : Assertion failed: v->stor_begin != NULL. This is an unexpected igraph error; please report this as a bug, along with the steps to reproduce it.
Please restart your R session to avoid crashes or other surprising behavior.

To get line numbers, the package must be loaded from the dev directory instead of the installed location.

library(devtools)
load_all()

gg <- make_ring(3, directed = TRUE)
V(gg)$id <- V(gg)
subgraph(gg, 1)

[szhorvat]

As far as I can tell, the NULL pointer is present in the eids_new2old vector which is initialized in igraph_i_induced_subgraph_create_from_scratch(), i.e. not R/igraph code. How does this become NULL? This is very strange and should be fully understood before closing this issue, as there's a potential of a more serious underlying issue. Is the finally stack being prematurely unwound? Let's not close this with a purely symptomatic fix.

[szhorvat]

Some more investigation (adding extra IGRAPH_ASSERTs) shows that eids_new2old.stor_begin becomes NULL during this call:

https://github.com/igraph/igraph/blob/release/0.9/src/operators/subgraph.c#L246

Copying the code with context and annotating it:

    /* Copy the graph attributes */
    IGRAPH_CHECK(igraph_i_attribute_copy(res, graph,
                                         /* ga = */ 1, /* va = */ 0, /* ea = */ 0));

    // eids_new2old is valid here

    /* Copy the vertex attributes */
    IGRAPH_CHECK(igraph_i_attribute_permute_vertices(graph, res,
                 my_vids_new2old));

    // eids_new2old is no longer valid here, eids_new2old.stor_begin is now NULL

    /* Copy the edge attributes */
    IGRAPH_CHECK(igraph_i_attribute_permute_edges(graph, res, &eids_new2old));

This makes no sense to me, since igraph_i_attribute_permute_vertices() doesn't even have access to eids_new2old. The only explanation I can think of is that something unwinds the finally stack without properly escaping. In other words, the implementation of R_igraph_attribute_permute_vertices() may be lacking some important error checks. @Antonov548, is this possible?

CC @ntamas