oqgraph-dev team mailing list archive

[Andrew McDonnell <bugs@xxxxxxxxxxxxxxxxxxx>]

Hi Arjen

(see also my other longer post!)

I am thinking the easiest route to start with is to change the return type if
init_tmp_table_share() to int and return an error; those other callers in the
system will ignore it for now as they already do

ha_oqgraph::open returns an error code, so it can do so in this case.


--Andrew

On 20/02/13 10:20, Arjen Lentz wrote:
> Hi Andrew
> 
> I think the create table statement is incomplete for v3, as in v3 there is no local storage but instead the columns need to be mapped onto cols of an existing base table (generally InnoDB).
> Antony, can you update us on the correct CREATE TABLE for v3?
> 
> 
>> INSERT INTO tol_tree (origid,destid)
>> SELECT parent,id FROM tol WHERE parent IS NOT NULL;
>>
>> this failed ... (stack trace attachment)
>>
>> I note the stack trace is full of mangled C++ identifiers ...
>>
>> I then ran mysqld from gdb. The fault repeated the same, but gdb let
>> me see the identifiers. (attach #2) and of course, catch the fault and
>> examine variables.
>>
>> It turns out that options->tablename in ha_oqgraph::open (-->
>> table_name in table.cc) is NULL. And strlen barfs because table.cc
>> isn't checking for a NULL.
>>
>> I am unfamiliar with the code as yet, so I don't know why this is
>> NULL.
>>
>> As an aside, I am used to working with code that is defensively laced
>> with assertions for NULL pointers, so this is a little different to me...
> 
> Well that's clearly an omission and a bug in the new code.
> Crashing a multi-threaded/multi-user daemon is not nice. So generally when something fails in MySQL, you have a mechanism to return a fail from that function.
> At the very least you'd have an assert in there (do add it), but obviously you'd want to code to not get into that situation in the first place
> 
> 
> Cheers,
> Arjen.