postgres-xc-developers Mailing List for Postgres-XC

Thanks for the pointing out.   Another requirement was to make mcxt.o
shared among gtm and gtm_proxy.   I will look check if this
requirement makes sense now (it did, when very first pgxc_clean was
implemented, which was rewritten at V 1.0).

I'm afraid the cause of NULL pointer is different.

Regards;
----------
Koichi Suzuki


2012/6/15 plexo rama <ple...@gm...>:
> Hello,
>
> today I downloaded & compiled postres-xc 1.0.0 from source.
> It worked like a charm with the exception of gtm_proxy. However,
> for some strange reason, the process wouldn't come up. I re-compiled
> the source using gcc version 4.4.3 (ubuntu 32bit) with -g3 -ggdb and fired
> up gdb to see what was going on. It took me quite some time to analyze
> the code structure & pin point the bug.
>
> I finally came up with the following result:
>
> The initial segfault was in MemoryContextAllocZero because of
> a NULL context passed by palloc0( ) macro.
> The CurrentMemoryContext macro result was 0x0.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x08068d10 in MemoryContextAllocZero (context=0x0, size=128) at mcxt.c:585
> 585             ret = (*context->methods->alloc) (context, size);
>
>
> Looking at "info macro CurrentMemoryContext", gdb gives me the following
> output
>
> (gdb) info macro CurrentMemoryContext
> Defined at ../../../src/include/gtm/gtm.h:106
>   included at pgxc/src/gtm/common/mcxt.c:28
> #define  CurrentMemoryContext GetMyThreadInfo->thr_current_context
>
> further more "info marco GetMyThreadInfo" shows the following
>
> (gdb) info macro GetMyThreadInfo
> Defined at ../../../src/include/gtm/gtm.h:104
>   included at pgxc/src/gtm/common/mcxt.c:28
> #define GetMyThreadInfo ((GTM_ThreadInfo
> *)pthread_getspecific(threadinfo_key)
>
>
> strangely enough, GetMyThread casts the return of pthread_getspecific()
> to GTM_ThreadInfo instead of GTMProxy_ThreadInfo.
>
>
> The problem:
>
> a) mcxt.c includes "gtm/gtm.h"
> b) the xxxxxMemoryContext macros use the wrong structure (GTM_ThreadInfo)
>
>
> The solution:
>
> mcxt.c should include "gtm/gtm_proxy.h" if compiled for gtm_proxy, otherwise
> use "gtm/gtm.h"
>
>
> 1) go to the src/gtm/proxy directory
> 3) create a soft-link to mcxt.c (ln -s ../common/mcxt.c )
> 2) edit mcxt.c and replace the #include "gtm/gtm.h" line with the following:
>
> #if !defined(GTM_PROXY)
> #include "gtm/gtm.h"
> #else
> #include "gtm/gtm_proxy.h"
> #endif
>
>
> 3) open Makefile for editing
>
> 3.1) insert the following line after "subdir=src/gtm/proxy"
>
> override CFLAGS += -DGTM_PROXY
>
> 3.2) add mcxt.o to OBJS
>
> 3.3) save & exit
>
> 4) make clean && make
>
>
> I'm just curious why no one has stumbled upon this error?
>
> Could it be the gcc-version I'm using?  Actually, to make sure
> its not the compiler, I downloaded clang and compiled
> the gtm/-tree. Unfortunately, gtm_proxy kept crashing.
>
> Are you able to replicate the errror?
>
>
> Cheers,
> Plexo
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>

Hello,

today I downloaded & compiled postres-xc 1.0.0 from source.
It worked like a charm with the exception of gtm_proxy. However,
for some strange reason, the process wouldn't come up. I re-compiled
the source using gcc version 4.4.3 (ubuntu 32bit)* *with -g3 -ggdb and
fired
up gdb to see what was going on. It took me quite some time to analyze
the code structure & pin point the bug.

I finally came up with the following result:

The initial segfault was in *MemoryContextAllocZero* because of
a *NULL context* passed by palloc0( ) macro.
The *CurrentMemoryContext *macro result was 0x0.

Program received signal SIGSEGV, Segmentation fault.
0x08068d10 in MemoryContextAllocZero (context=0x0, size=128) at mcxt.c:585
585             ret = (*context->methods->alloc) (context, size);


Looking at "*info macro CurrentMemoryContext*", gdb gives me the following
output

(gdb) info macro CurrentMemoryContext
Defined at ../../../src/include/gtm/gtm.h:106
  included at pgxc/src/gtm/common/mcxt.c:28
#define  CurrentMemoryContext GetMyThreadInfo->thr_current_context

further more "*info marco GetMyThreadInfo*" shows the following

(gdb) info macro GetMyThreadInfo
Defined at ../../../src/include/*gtm/gtm.h*:104
  included at pgxc/src/gtm/*common/mcxt.c*:28
#define GetMyThreadInfo ((*GTM_ThreadInfo **
)pthread_getspecific(threadinfo_key)


strangely enough, GetMyThread casts the return of pthread_getspecific()
to *GTM_ThreadInfo* instead of *GTMProxy_ThreadInfo*.


The problem:

a) mcxt.c includes "gtm/gtm.h"
b) the xxxxxMemoryContext macros use the wrong structure (GTM_ThreadInfo)


The solution:

mcxt.c should include "gtm/gtm_proxy.h" if compiled for gtm_proxy,
otherwise use "gtm/gtm.h"


1) go to the src/gtm/proxy directory
3) create a soft-link to mcxt.c (ln -s ../common/mcxt.c )
2) edit mcxt.c and replace the #include "gtm/gtm.h" line with the following:

#if !defined(GTM_PROXY)
#include "gtm/gtm.h"
#else
#include "gtm/gtm_proxy.h"
#endif


3) open Makefile for editing

3.1) insert the following line after "subdir=src/gtm/proxy"

override CFLAGS += -DGTM_PROXY

3.2) add mcxt.o to OBJS

3.3) save & exit

4) make clean && make


I'm just curious why no one has stumbled upon this error?

Could it be the gcc-version I'm using?  Actually, to make sure
its not the compiler, I downloaded clang and compiled
the gtm/-tree. Unfortunately, gtm_proxy kept crashing.

Are you able to replicate the errror?


Cheers,
Plexo

On Thu, Jun 14, 2012 at 09:17:18AM +0530, Ashutosh Bapat wrote:
> First I object to committing anything without sending it on developers list
> and getting comments, however miniscule it is. That process is followed in

Not sure if it makes sense to bring up my $0.02, but I doubt this will help in
the long run. IMO it will slow development and make this ML almsot useless if
even small typo fixes need to be discussed.

> PG and we should follow the same in XC, for the sake of sanity of code.

This btw is not true. You are not expected to send and discuss minor patches in
PG. If you know what you're doing ou can simply commit it. After all we're
using git, right? You can easily revert a patch there, can't you?

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

On Thu, Jun 14, 2012 at 12:47 PM, Ashutosh Bapat <
ash...@en...> wrote:

>
>
> On Thu, Jun 14, 2012 at 5:18 AM, Michael Paquier <
> mic...@gm...> wrote:
>
>> (Just a note, the committers mailing list is not made for discussions. In
>> case you wish to discuss of a commit, please forward it to the developers
>> ML first and then launch a new discussion thread.)
>>
>
> First I object to committing anything without sending it on developers
> list and getting comments, however miniscule it is. That process is
> followed in PG and we should follow the same in XC, for the sake of sanity
> of code. Now, that you have committed it, the committers' mailing list is
> the best option.
>
Just two arguments here:
1) There may be people who only register to the commit ML just to follow
the commit history in XC's GIT repository and do not really care about
hackers discussion. This gives a sufficient reason to keep the commit ML
clean of any discussion related to them.
2) If you have a look at how postgres folks manage their mailing lists, you
will see that all the discussions about commits are transferred to the
hackers mailing list when a discussion on a commit occurs. The subject in
the email remaining the same as when the commit mail was generated.

Thanks,
-- 
Michael Paquier
http://michael.otacoo.com

On Thu, Jun 14, 2012 at 5:18 AM, Michael Paquier
<mic...@gm...>wrote:

> (Just a note, the committers mailing list is not made for discussions. In
> case you wish to discuss of a commit, please forward it to the developers
> ML first and then launch a new discussion thread.)
>

First I object to committing anything without sending it on developers list
and getting comments, however miniscule it is. That process is followed in
PG and we should follow the same in XC, for the sake of sanity of code.
Now, that you have committed it, the committers' mailing list is the best
option.


>
> On Wed, Jun 13, 2012 at 8:39 PM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>> Hi Michael,
>> Since you have changed the join.sql itself it's better to change the
>> join.out along with join_1.out with the changed plan. The plan is only
>> changed in join_1.out and not join.out. Otherwise, when we will come to
>> remove join_1.out, we will have difficulty deciding the correct one out of
>> the two variations.
>
> The plans were not consistent also before this commit as join.out gives
> the output of vanilla postgres.
>

For the changed query the vanilla postgres output does not match that in
join.out file. Also, the output from vanilla postgres is not valid in XC as
far as the plan outputs are considered. Hence those need to change. I
didn't get the meaning of first part of your sentence, what was not
consistent in the plans?


> --
> Michael Paquier
> http://michael.otacoo.com
>



-- 
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company

9.2 stable branch has been created in postgres git repository a couple of
hours ago.
It is now possible to plug-in Postgres-XC code with 9.2.

Regards,

Michael

---------- Forwarded message ----------
From: <pg...@po...>
Date: Thu, Jun 14, 2012 at 8:57 AM
Subject: [COMMITTERS] pgsql: Branch refs/heads/REL9_2_STABLE was created
To: pgs...@po...


Branch refs/heads/REL9_2_STABLE was created.

View: http://git.postgresql.org/pg/shortlog/refs/heads/REL9_2_STABLE
--
Sent via pgsql-committers mailing list (pgs...@po...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers



-- 
Michael Paquier
http://michael.otacoo.com