Drag'n Drop issue

Hi,

I’m getting a segfault in PtConnectorGetId called
by PtGetTransportVectors which is it-self called by
PtInitDnd. This occurs only when I use PtTransportType
to fill a simple string in a PtTransportCtrl_t.

Here what i do in the outbound CB :

PtTransportCtrl_t *ctrl;

ctrl = PtCreateTransportCtrl();
if(ctrl)
{
PtTransportType(ctrl,“zSDK”,“text”,0,Ph_TRANSPORT_INLINE,
“string”,foo,strlen(foo),0);
PtInitDnd(ctrl,widget,info->event,NULL,0);
}

If I comment the PtTransportType, of set the vdata args to NULL,
there is no crash and the drag’n drop works.

thanks for any help.

Regards,

jean-louis

Where are you definig foo? What is the definition for foo?

Thanks,
Rodney

Jean-Louis Villecroze wrote:

Hi,

I’m getting a segfault in PtConnectorGetId called
by PtGetTransportVectors which is it-self called by
PtInitDnd. This occurs only when I use PtTransportType
to fill a simple string in a PtTransportCtrl_t.

Here what i do in the outbound CB :

PtTransportCtrl_t *ctrl;

ctrl = PtCreateTransportCtrl();
if(ctrl)
{
PtTransportType(ctrl,“zSDK”,“text”,0,Ph_TRANSPORT_INLINE,
“string”,foo,strlen(foo),0);
PtInitDnd(ctrl,widget,info->event,NULL,0);
}

If I comment the PtTransportType, of set the vdata args to NULL,
there is no crash and the drag’n drop works.

thanks for any help.

Regards,

jean-louis

In <3EA56B27.7070504@qnx.com> Rodney Dowdall wrote:

Where are you definig foo? What is the definition for foo?

Hi Rodney,

Thanks for replying. foo is a global char * … I tried also
replacing foo with strdup(“hello”) … whatever I put I get
a segfault …

jl

Jean-Louis Villecroze wrote:

In <> 20030423124315695+0200@inn.qnx.com> > Jean-Louis Villecroze wrote:

In <> 3EA56B27.7070504@qnx.com> > Rodney Dowdall wrote:

Where are you definig foo? What is the definition for foo?

Hi Rodney,

Thanks for replying. foo is a global char * … I tried also
replacing foo with strdup(“hello”) … whatever I put I get
a segfault …

jl


Actually the issue seems to be that I’m using a thread to run
PtMainLoop() … why is that ?

jl

Because Photon is not multi threaded. I would suggest that you do not
but PtMainLoop in a seperate application. If you want to have multiple
threads, then use the PtEnter and PtLeave calls around any Photon calls
that you are going to be doing inside of the threads.

Thanks,
Rodney

In <20030423124315695+0200@inn.qnx.com> Jean-Louis Villecroze wrote:

In <> 3EA56B27.7070504@qnx.com> > Rodney Dowdall wrote:
Where are you definig foo? What is the definition for foo?

Hi Rodney,

Thanks for replying. foo is a global char * … I tried also
replacing foo with strdup(“hello”) … whatever I put I get
a segfault …

jl

Actually the issue seems to be that I’m using a thread to run
PtMainLoop() … why is that ?

jl

Jean-Louis Villecroze <jlv@nospam.kirilla.com> wrote:

Actually the issue seems to be that I’m using a thread to run
PtMainLoop() … why is that ?

Are you calling PtEnter() before PtMainLoop()?


Wojtek Lerch QNX Software Systems Ltd.

Because Photon is not multi threaded. I would suggest that you do not
but PtMainLoop in a seperate application. If you want to have
multiple threads, then use the PtEnter and PtLeave calls around any
Photon calls that you are going to be doing inside of the threads.

I’m well aware of multi-threaded issues of Photon, but the crash
occurs in a Photon CB (which AFAIK is PtEnter/PtLeave protected
inside the PtMainLoop) … I will post some code later.

thanks.

jl

In <b870m3$qre$1@inn.qnx.com> Wojtek Lerch wrote:

Jean-Louis Villecroze <> jlv@nospam.kirilla.com> > wrote:
Actually the issue seems to be that I’m using a thread to run
PtMainLoop() … why is that ?

Are you calling PtEnter() before PtMainLoop()?

hmm … no, not before … should I ? I always call it when
a thread is doing some Photon calls …

thanks for the answer.

jl

Hello,

Using the Drag&Drop example from one of the QNX
article, I was able to reproduce the issue in
standard Photon.

It seems that the crash in PtConnectorGetId occurs
ONLY when I’m creating a dispatch handle and attach
to it a CB for message.

I attached the photon C example to this post, recompile
it and try to drag the element “one” from the list …

Regards,

jean-louis




begin 644 FOO.C
M(VEN8VQU9&4@/’-T9&EO+F@^“B-I;F-L=61E(#QP:&]T;VXO4’10<F]T;RYH
M/@HC:6YC;'5D92\<&AO=&]N+U!T5VED9V5T+F@^"B-I;F-L=61E(#QP:&]T M;VXO4'17:6YD;W<N:#X*(VEN8VQU9&4@/'!H;W1O;B]0=$QI<W0N:#X*(VEN M8VQU9&4@/'!H;W1O;B]0=%1E>'0N:#X*(VEN8VQU9&4@/'!H;W1O;B]0=$)U M='1O;BYH/@H*(VEN8VQU9&4@/'-Y<R]N975T<FEN;RYH/@HC:6YC;'5D92
M<WES+VYE=&UG<BYH/@HC:6YC;'5D92\<WES+VEO9G5N8RYH/@HC:6YC;'5D M92<WES+V1I<W!A=&-H+F@^”@H@+R@0W)E871E(&$@8VAE8VME<F)O87)D
M(#$V>#$V(&EM86=E+@H@4&A);6%G95]T(“IC<F5A=&5?8VAE8VME<F)O87)D
M*’-H;W)T(&-O;&]R,2QS:&]R=”!C;VQO<C(I"B![“B@(%!H26UA9V5?="J
M:3L*(”@4&A'0U]T("IO9V,["B@(&-H87(@F)I=’,["B@(&EN="!A+&([ M"@H@("!I/5!H0W)E871E26UA9V4H3E5,3"PQ-BPQ-BQ09U])34%'15]$25)% M0U1?-38U+$Y53$PL,"PQ*3L*("@8FET<SUI+3YI;6%G93L("@9F]R("AA M/3[83PQ-CMARLL8FET<RL]:2T^8G!L0H@(“@(&9O<BH8CTP.V(,38[
M8BLK0H@("@("@“AS:&]R=“HI8FET<RE;8ET]"@H82\R2LH8B\R2DF
M,2D_8V]L;W(Q.F-O;&]R,CL
"B@(')E='5R;B!I.PH@?0H*:6YT(&QI<W1? M;W5T8F]U;F0H4'17:61G971?="J=VED9V5T+'9O:60@F1A=&$L4’1#86QL
M8F%C:TEN9F]?=“J8V)I;F9O*0H@>PH@("!0:%!O:6YT97)%=F5N=%]T("IP M978@/2H4&A0;VEN=&5R179E;G1?=”J*5!H1V5T1&%T82AC8FEN9F\M/F5V M96YT*3L*"B@("\O(&UA:V4@<W5R92!W92!H879E(‘1H92!L969T(“AS96QE
M8W1I;VXI(&)U='1O;B!P<F5S<V5D"B@(&EF("AP978M/F)U='1O;G,F4&A? M0E545$].7U-%3$5#5"D*("@>PH@(”@('5N<VEG;F5D('-H;W)T("II;F0[ M"B@("@<VAO<G0@*FYU;3L*"B@("@+R\@9V5T('1H92!L:7-T(&]F(&EN M9&5X97,@*'1H97)E(&-A;B!B92!O;FQY(&]N92$I"B@("@4'1'971297-O M=7)C92AW:61G970L4'1?05)'7U-%3$5#5$E/3E])3D1%6$53+"9I;F0L)FYU M;2D["@H@("@("\O(&UA:V4@<W5R92!T:&5R92=S(&$@<V5L96-T960@:71E
M;0H@("@(&EF("@H*FYU;2D^,"D*("@("![“B@("@(”!C:&%R(“HJ:71E
M;7,[“B@("@(”!0=%1R86YS<&]R=$-T<FQ?=”J=&-T<FP]4'1#<F5A=&54 M<F%N<W!O<G1#=')L*"D["@H@("@("@+R\@9V5T('1H92!L:7-T(&]F(&ET M96US"B@("@("!0=$=E=%)E<V]U<F-E*'=I9&=E="Q0=%]!4D=?251%35,L M)FET96US+"9N=6TI.PH*("@("@("\O(&%D9"!A;B!I;FQI;F4@<&QA:6X@ M=&5X="!T<F%N<W!O<G0@=&\@=&AE(&1R86<@86YD(&1R;W@=’)A;G-P;W)T
M(H@("@("@+R\@8V]N=')O;"P@;6%K:6YG('-U<F4@=V4@<F5M96UB97(@ M=&AA="!I;F1E>&5S('-T87)T(&%T(#$@:6X@=&AE(&QI<W0*("@("@(%!T M5')A;G-P;W)T5'EP92AT8W1R;"PB=&5X="(L(G!L86EN(BPP+%!H7U1204Y3 M4$]25%])3DQ)3D4L"B@("@("@(")S=’)I;F<B+&ET96US6VEN9%LP72TQ
M72PP+#I.PH)"B@(“@("O+R!S=&%R=”!T:&4@9’)A9R!A;F0@9’)O<H@ M("@("@4'1);FET1&YD*'1C=')L+'=I9&=E="QC8FEN9F\M/F5V96YT+$Y5 M3$PL4'1?1$Y$7U-)3$5.5"D["B@("@?0H@("!]"B@(’)E='5R;B!0=%]#
M3TY424Y513L
('T@”@II;G0@;7-G7VAA;F1L97(H;65S<V%G95]C;VYT97AT
M7W0@F-T<“QI;G0@8V]D92QU;G-I9VYE9”!F;&%G<RQV;VED("IH86YD;&4I
M"GL
"7)E=‘5R;BP.PI]"@H@:6YT(&UA:6XH*0H@>PH@("!0=$%R9U]T(&%R M9W-;-5T["B@(%!T5VED9V5T7W0@G=I;BPJ;&ES="PJ=&5X="PJ8G5T=&]N
M,2PJ8G5T=&]N,BPJ8G5T=&]N,SL
(“@4&A);6%G95]T("II;6%G93$L*FEM M86=E,BPJ:6UA9V4S.PH@("!0:$1I;5]T(&1I;3U[,CP+#,P,‘T[“B@(%!H M4&]I;G1?="!P;W,]>S4P+#4P?3L*("@8VAA<BJ:71E;7-;73U[(F]N92(L M(G1W;R(L(G1H<F5E(BPB9F]U<B)].PH)"@DO+R!C<F5A=&4@9&ES<&%T8V@@ M:&%N9&QE(&%N9"!A='1A8V@@;65S<V%G92!#0@H)"@ED:7-P871C:%]T("ID M<'[”@EM97-S86=E7V%T=’)?=”!A=‘1R.PH*"6%T=’(N9FQA9W,@"0D)/2!-
M4T=?1DQ!1U]$149!54Q47T953D,[(H)871T<BYN<&%R='-?;6%X(D](#$[
M("@(D)"0D)“0H)871T<BYM<V=?;6%X7W-I>F4)/2Q,#[(”@"0D)"0H* M"61P<"](&1I<W!A=&-H7V-R96%T92@I.PH"6EF&1P<"D*"0EM97-S86=E
M7V%T=&%C:"AD<’L)F%T='(L,"PP+&US9U]H86YD;&5R+$Y53$PI.PH*"2\O M(&1O('!H;W1O;B!S='5F9@H*"5!T26YI="A.54Q,*3L*"B@(”\O(&-R96%T
M92!O=7(@=VEN9&]W"B@(%!T4V5T07)G*"9A<F=S6S!=+%!T7T%21U]$24TL M)F1I;2PP*3L*("@4’13971!<F<H)F%R9W-;,5TL4’1?05)'7U!/4RPF<&]S
M+#I.PH@("!0=%-E=$%R9R@F87)G<ULR72Q0=%]!4D=?5TE.1$]77U1)5$Q% M+")$<F%G;VX@1')O<'!I;F=S(BPP*3L*("@=VEN/5!T0W)E871E5VED9V5T
M*%!T5VEN9&]W+%!T7TY/7U!!4D5.5"PS+&%R9W,I.PH*(“@+R\@8W)E871E M(&]U<B!T97AT('=I9&=E=H@(”!D:6TN=STQ-3[9&EM+F@],C4[<&]S+G@] M,C4[<&]S+GD],CP.PH@(”!0=%-E=$%R9R@F87)G<ULR72Q0=%]!4D=?1DQ!
M1U,L4’1?5%)512Q0=%]314Q%0U1!0DQ%?%!T7U-%3$5#5%].3U)%1%)!5RD[
M"B@('1E>'0]4'1#<F5A=&57:61G970H4'1497AT+'=I;BPS+&%R9W,I.PH* M("@+R@8W)E871E(&]U<B!L:7-T(’=I9&=E=H@("!D:6TN=SUD:6TN:#TQ M-3[<&]S+G@]<&]S+GD],C4[“B@(&QI<W0]4'1#<F5A=&57:61G970H4'1, M:7-T+'=I;BPS+&%R9W,I.PH)"@E0=$%D9$-A;&QB86-K*&QI<W0L4'1?0T)? M3U540D]53D0L;&ES=%]O=71B;W5N9"PP*3L@"@D*("@+R@861D(&$@9F5W
M(&ET96US(‘1O(&]U<B!L:7-T(’=I9&=E=H@("!0=$QI<W1!9&1)=&5M<RAL M:7-T+"AC;VYS="!C:&%R("HJ*6ET96US+#0L,2D["@H@("!I;6%G93$]8W)E M871E7V-H96-K97)B;V%R9"@P>&9F-SL,’@P,#P*3L*("@:6UA9V4R/6-R
M96%T95]C:&5C:V5R8F]A<F0H,’@P-V9F+#!X9F9F9BD[“B@(&EM86=E,SUC M<F5A=&5?8VAE8VME<F)O87)D*#!X,#P,“PP>&9F9F8I.PH*(”@+R\@8W)E M871E(&9I<G-T(&)U='1O;B!W:61G971S"B@(&1I;2YW/61I;2YH/3(V.W!O
M<RYX/3(U.W!O<RYY/3(U,#L*(”@4'13971!<F<H)F%R9W-;,ETL4'1?05)' M7TQ!0D5,7U194$4L4'1?24U!1T4L,"D["B@(%!T4V5T07)G*“9A<F=S6S-=
M+%!T7T%21U],04)%3%])34%‘12QI;6%G93$L,"D[“B@(&)U='1O;C$]4'1# M<F5A=&57:61G970H4'1"=71T;VXL=VEN+#0L87)G<RD["@H@("O+R!C<F5A
M=&4@<V5C;VYD(&)U=‘1O;B!W:61G970*(“@<&]S+G@],34P.PH@("!0=%-E M=$%R9R@F87)G<ULS72Q0=%]!4D=?3$%"14Q?24U!1T4L:6UA9V4R+#I.PH@
M(”!B=71T;VXR/5!T0W)E871E5VED9V5T*%!T0G5T=&]N+’=I;BPT+&%R9W,I
M.PH*(”@+R\@8W)E871E(&]U<B!T:&ER9"!B=71T;VX@=VED9V5T"B@(’!O
M<RYX/3<X.V1I;2YW/34P.PH@(”!0=%-E=$%R9R@F87)G<ULS72Q0=%]!4D=?
M3$%“14Q?24U!1T4L:6UA9V4S+#I.PH@("!B=71T;VXS/5!T0W)E871E5VED M9V5T*%!T0G5T=&]N+'=I;BPT+&%R9W,I.PH*("@4’1296%L:7IE5VED9V5T
:*’=I;BD[”@H)4’1-86EN3&]O<”@I.PI]"@H
end

Jean-Louis Villecroze <jlv@nospam.kirilla.com> wrote:

In <b870m3$qre$> 1@inn.qnx.com> > Wojtek Lerch wrote:
Jean-Louis Villecroze <> jlv@nospam.kirilla.com> > wrote:
Actually the issue seems to be that I’m using a thread to run
PtMainLoop() … why is that ?

Are you calling PtEnter() before PtMainLoop()?

hmm … no, not before … should I ? I always call it when
a thread is doing some Photon calls …

PtMainLoop() is a Photon call, too, and requires that you have the
Photon lock when you call it. You don’t need to call PtEnter() after
PtInit() because PtInit() returns with the library locked; but in any
thread other than the one that called PtInit(), you must call PtEnter()
first.

(What happens is that when PtMainLoop() is about to wait for an event,
it calls PtLeave(). If no thread has the lock, PtLeave() will crash
right away. But if a different thread has the lock, PtLeave() will
happily unlock the library, as if that other thread called it; sooner or
later, you’ll either end up with two threads thinking that they have the
lock and corrupting some internal data, or a PtLeave() call will crash
because the library wasn’t locked by anybody.

(Disclaimer: the above is just an explanation of what I expect to happen
in the current version of Photon library. Don’t consider this an
official promise that anything similar will happen in future versions of
Photon, too. If you call PtLeave() from a thread that doesn’t have the
lock, whatever happens is your fault.))

BTW Make sure that the thread that calls PtMainLoop() has plenty of
stack. The default size is way too little.

Hi,

Thanks for the extra info Wojtek. Actually the issue
I encounter is stated in a reply to Rodney in the
first thread of the original post :

Using the Drag&Drop example from one of the QNX
article, I was able to reproduce the issue in
standard Photon.

It seems that the crash in PtConnectorGetId occurs
ONLY when I’m creating a dispatch handle and attach
to it a CB for message.

I attached the photon C example to this post, recompile
it and try to drag the element “one” from the list …

I attached the source code of the example in the post.

Cheers,

jean-louis

BTW Make sure that the thread that calls PtMainLoop() has plenty of
stack. The default size is way too little.

how much should I set ?

Wojtek Lerch <wojtek_l@yahoo.ca> wrote:

Jean-Louis Villecroze <> jlv@nospam.kirilla.com> > wrote:

BTW Make sure that the thread that calls PtMainLoop() has plenty of
stack. The default size is way too little.

It is? I thought the default was 128K. (And 512K for thread1.)

Is 128K really too small?

(Ok, on x86 it is 128K – don’t know about other platfroms.)

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

David Gibbs <dagibbs@qnx.com> wrote:

Wojtek Lerch <> wojtek_l@yahoo.ca> > wrote:
Jean-Louis Villecroze <> jlv@nospam.kirilla.com> > wrote:

BTW Make sure that the thread that calls PtMainLoop() has plenty of
stack. The default size is way too little.

It is? I thought the default was 128K. (And 512K for thread1.)

Not according to my copy of our docs:

pthread_attr_setstacksize()

Arguments:

stacksize
The size of the stack you want to use in new threads. The default and
minimum value of the thread stack-size attribute is PTHREAD_STACK_MIN.

Caveats:

The QNX interpretation of PTHREAD_STACK_MIN is enough memory to run a
thread that does nothing:

void nothingthread( void )
{
return;
}

Wojtek Lerch <wojtek_l@yahoo.ca> wrote:

David Gibbs <> dagibbs@qnx.com> > wrote:
Wojtek Lerch <> wojtek_l@yahoo.ca> > wrote:
Jean-Louis Villecroze <> jlv@nospam.kirilla.com> > wrote:

BTW Make sure that the thread that calls PtMainLoop() has plenty of
stack. The default size is way too little.

It is? I thought the default was 128K. (And 512K for thread1.)

Not according to my copy of our docs:

PTHREAD_STACK_MIN is messy and unclear. PTHREAD_STACK_MIN is the
minimum and default value for the attribute structure entry stacksize
(kind of), but not for the thread’s stack itself.

That is, it isn’t the minimum that we give a thread by default.

It is the mimimum that a person supplying their own stack for a thread
must supply for the thread to be able to start.

So, if you’re doing:

stack_ptr = malloc( stack_size );

Then stack_size must be >= PTHREAD_STACK_MIN.

But, if you’re just allowing us to create a stack for the thread – well,
you’ll get at mimimum 1 page (4k) of memory, and in fact [at least on
x86] we default to 128K virtual (demand-allocate), one 4k guard page,
and always at least the first page (4k) actually allocated.

So, in conclusion, the default stack for threads will, actually,
be ok.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

David Gibbs <dagibbs@qnx.com> wrote:

Wojtek Lerch <> wojtek_l@yahoo.ca> > wrote:
David Gibbs <> dagibbs@qnx.com> > wrote:
Wojtek Lerch <> wojtek_l@yahoo.ca> > wrote:

BTW Make sure that the thread that calls PtMainLoop() has plenty of
stack. The default size is way too little.

It is? I thought the default was 128K. (And 512K for thread1.)

Not according to my copy of our docs:

PTHREAD_STACK_MIN is messy and unclear.

I’ll let the docs writers know.