[Nauty-list] readgraph()

[William Rummler]

It seems like the segfault from both source files was being caused by
incorrect arguments in the call to nauty(). For instance, lab, ptn,
and orbits were declared as int pointers without later (but before the
call to nauty()) being assigned addresses of allocated memory. Also,
stats was declared as a pointer to statsblk when it probably should
have been declared as a statsblk and had its address given to nauty()
as &stats.

Regarding the graph-reading code in testnau3.c, there seemed to be a
few minor typos that were causing (or could cause) bad program
behavior, at least some of the time: in the dateianfang2-labeled
section, the else-clause seems like it should be assigning dateiname2,
not dateiname; thus, in the following call to opengraphfile(),
dateiname2 should be passed, not dateiname; finally, there was a
printf() call on line 155 where it looked like you accidentally
dereferenced Dateiname before passing it in correspondence to a '%s'
format flag.

In the last two code sections where putgraph() is called, there were a
few more typos. First, the index variable of the enclosing for-loop
was ni, while the variable used with the graph expression was i.
Second, the arguments l and m are transposed in the calls to
putgraph().

After I edited the code to account for these notes, it seemed to read
your input, run, and output without error.

- William

On Thursday, February 3, 2011,  <niess at ma.tum.de> wrote:
> Sorry, I feared that my e-mail would become too big if I included the
> whole program text. This time I will attach testnau3.c and testnau4.c; the
> first has the problem with reading a file, the last causes a segmentation
> fault with nauty. testnau4 doesn't make much sense, it is just to test
> nauty. The files that I try to read were jba030_3 and jbc030_3. testnau3
> first reads jbc030_3 and then jba030_3, testnau4 only reads jbc030_3.
> jba030_3 has been made by geng and contains only one graph, jbc030_3
> contains the same graph in an other format, with a header, and my own
> programs can read it. It is the graph with 3 nodes and 3 edges.
>
> To William: Unfortunately I think that does not help me. As far as I have
> understood, the format graph6 is different from the internally used format
> in which graphs in the packed form are used by functions like nauty.
> Especially I think the internal format does not have 163 added, does it?
> So if ntog6 convets something to graph6, this is not what I really need. I
> need to convert the adjacency  matrix (given as integers) to a form that I
> can give to nauty.
>>
>> The gtools function ntog6() will convert a graph datatype to a C
>> string containing that graph's graph6 representation. The gtools
>> function writeg6() uses ntog6() to output a graph's graph6
>> representation to a given stream. There are similar and
>> similarly-named functions for sparse graphs.
>>
>>
>> If the above comments don't help, then I think it would be
>> considerably easier to help you debug your program's segfault if you
>> gave the input (and the minimum compilable source) necessary to
>> reproduce it. Otherwise, the process can be unnecessarily inefficient.
>>
>