Skip site navigation (1) Skip section navigation (2)

Re: help for "quick search"

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Akos Marton <makos999(at)gmail(dot)com>
Cc: Levente Torok <toroklev(at)gmail(dot)com>, pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: help for "quick search"
Date: 2009-03-16 09:03:14
Message-ID: 937d27e10903160203w55d22f09m625428169a7c450e@mail.gmail.com (view raw or flat)
Thread:
Lists: pgadmin-hackers
[Please keep messages on list]

On Mon, Mar 16, 2009 at 2:49 AM, Akos Marton <makos999(at)gmail(dot)com> wrote:
> Hi Dave,
>
> Thanks your answer and advices!
> I've done your corrections and the results didn't changed. I don't
> understand what is the problem. Here's a backtrace for the example. I
> am interested in the solution of this problem, or some advice, where
> could I post any question to know the answer for this segfault - why
> isn't it working on Linux and why is it working on Windows? -.
> Until these answers I am working on another solution to dodge this.
>

Post your questions to the pgadmin-hackers mailing list - that's where
we discuss this sort of thing.

>> The only crash I could get in the debugger was if I searched for
>> 'Dummy'. The treeview often has dummy nodes attached which the user
>> never sees - these aren't linked to an object , so when you do this:
>> currentObject=browser->GetObject(item);
>
> I removed the Dummies.

OK

>> treee->AppendItem(treee->GetRootItem(), browser->GetItemText(item),
>> currentObject->GetIconId(), -1, currentObject);
>>
>> you end up with currentObject == NULL which results in a crash.
>>
>> From what I can see in the patch, it looks like you're testing on
>> Linux - I do the bulk of my debugging on Windows as the MSVC++
>> debugger makes it much easier. My guess is the different OS is the
>> reason why you see a crash and I don't, however, I suspect it's
>> happening because you're modifying currentObject which you should
>> almost certainly not be touching.
>
> I'm using another variable.

OK.

> It may couldn't help, but perhaps...
> backtrace 1: http://pastebin.com/m2c1681e9 search for second times with my code
> backtrace 2: http://pastebin.com/m3f5caa18 using another function in
> pgadmin, after use my search

What *exactly* are the steps your using to recreate the problem?

The only thing that stands out in the back traces is in the second one:

0x08211e62 in frmMaintenance (this=0x91b1800, form=0x8cb8108, obj=0x0)
at ./frm/frmMaintenance.cpp:54

The line it's crashing on (54) is trying to use the variable 'object'
which is set to the value of 'obj' in in
ExecutionDialog::ExecutionDialog. As you can see, that is null which
is why it crashes. You need to traverse back up the stack and see
where that value is coming from. Understanding how it gets set to null
when it clearly should be a pointer to a valid object also requires
understanding exactly what steps you follow to cause the problem in
the first place.


-- 
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

In response to

pgadmin-hackers by date

Next:From: Dave PageDate: 2009-03-16 09:16:02
Subject: Re: Support for sslverify
Previous:From: Quan ZongliangDate: 2009-03-16 08:43:49
Subject: Re: pgAdminIII 1.10 Visual Tour

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group