pthread_mutex_lock() bug ??

pthread_mutex_lock() bug ??

Post by son.. » Mon, 04 Sep 2000 04:51:49



I wrote the following little piece of code expecting it not to work
since I thought only the thread that locked a mutex should be capable
of unlocking it ( Mutex is ownership based ).
But to mu surpsrise a mutex that was locked in main() could be unlocked
by a spawned thread. Is this a bug in solaris implementation, or did I
miss something.
--------------
#include<iostream.h>
#include<unistd.h>
#include<pthread.h>

pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;

void * tester( void* ) {
pthread_mutex_lock( &m ) ;
cerr<<"OK I LOCKED the thread\n"<<endl ;
return NULL ;

Quote:}

void * unlocker( void* ) {
sleep( 3) ;
cerr<<"OK I UNLOCKED the thread\n"<<endl ;
pthread_mutex_unlock( &m ) ;
return NULL ;

Quote:}

int main() {

pthread_t t1, t2 ;
pthread_mutex_lock( &m ) ;
pthread_create( &t1, NULL, tester, NULL ) ;
pthread_create( &t2, NULL, unlocker, NULL ) ;
pthread_join( t1, NULL ) ;
pthread_join( t2, NULL ) ;

return 0;

Quote:}

-----------------------------

Can somebody please explain.
Thanks
Sony

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

pthread_mutex_lock() bug ??

Post by Andrew Su » Mon, 04 Sep 2000 07:36:04



> I wrote the following little piece of code expecting it not to work
> since I thought only the thread that locked a mutex should be capable
> of unlocking it ( Mutex is ownership based ).
> But to mu surpsrise a mutex that was locked in main() could be unlocked
> by a spawned thread. Is this a bug in solaris implementation, or did I
> miss something.
> --------------
> #include<iostream.h>
> #include<unistd.h>
> #include<pthread.h>

> pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;

> void * tester( void* ) {
> pthread_mutex_lock( &m ) ;
> cerr<<"OK I LOCKED the thread\n"<<endl ;
> return NULL ;
> }

> void * unlocker( void* ) {
> sleep( 3) ;
> cerr<<"OK I UNLOCKED the thread\n"<<endl ;
> pthread_mutex_unlock( &m ) ;
> return NULL ;
> }

> int main() {

> pthread_t t1, t2 ;
> pthread_mutex_lock( &m ) ;
> pthread_create( &t1, NULL, tester, NULL ) ;
> pthread_create( &t2, NULL, unlocker, NULL ) ;
> pthread_join( t1, NULL ) ;
> pthread_join( t2, NULL ) ;

> return 0;
> }
> -----------------------------

> Can somebody please explain.
> Thanks
> Sony

You've missed a few things.
They are . . .

There's no way of knowing whether the unlock was successful.
The program doesn't check for errors after making the
pthread_mutex_unlock call.

Since the mutex type appears to be the default PTHREAD_MUTEX_NORMAL,
if a thread unlocks a mutex that it has not locked,
the behavior is undefined.  The mutex type needs to be
PTHREAD_MUTEX_ERRORCHECK for the unlock operation to
fail with an EPERM error.  A "man pthread_mutex_unlock"
provides further details.

To change the mutex type in your program, add these in main(). . .

pthread_mutexattr_t mattr;

pthread_mutexattr_init( &mattr );
pthread_mutexattr_settype( &mattr, PTHREAD_MUTEX_ERRORCHECK );
pthread_mutex_init( &m, &mattr );

--
"Using & Managing PPP," http://www.oreilly.com/catalog/umppp

 
 
 

pthread_mutex_lock() bug ??

Post by Andrew Giert » Mon, 04 Sep 2000 07:49:00


 sonyea> I wrote the following little piece of code expecting it not
 sonyea> to work since I thought only the thread that locked a mutex
 sonyea> should be capable of unlocking it (Mutex is ownership based).

It's your responsibility, by default, to make sure that only the
thread that locks a mutex tries to unlock it. Otherwise the behaviour
is undefined.

If you want mutex locking to be error-checked, you need to create the
mutex with the PTHREAD_MUTEX_ERRORCHECK type attribute.

p.s. given that your code didn't contain any error checking, how
exactly were you expecting it not to work?

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
                           or <URL: http://www.whitefang.com/unix/>

 
 
 

pthread_mutex_lock() bug ??

Post by Kaz Kylhe » Mon, 04 Sep 2000 08:20:31



>I wrote the following little piece of code expecting it not to work
>since I thought only the thread that locked a mutex should be capable
>of unlocking it ( Mutex is ownership based ).
>But to mu surpsrise a mutex that was locked in main() could be unlocked
>by a spawned thread. Is this a bug in solaris implementation, or did I
>miss something.

Yes; you missed that undefined behavior can do anything; for instance make
demons fly out of your nose. ;)

Quote:>void * tester( void* ) {
>pthread_mutex_lock( &m ) ;
>cerr<<"OK I LOCKED the thread\n"<<endl ;
>return NULL ;
>}

>void * unlocker( void* ) {
>sleep( 3) ;
>cerr<<"OK I UNLOCKED the thread\n"<<endl ;
>pthread_mutex_unlock( &m ) ;
>return NULL ;

Umm, how do you know that it actually worked? You aren't checking any return
values. For all you know, pthread_mutex_unlock(&m) might have returned the
non-zero return code EPERM. An implementation is permitted to, but not required
to, check for the error of a thread unlocking a mutex it does not own.
Requiring implementations to check for this error would introduce needless
overhead in programs that are correct, and which hence do not bother testing
the return value.

--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.

 
 
 

pthread_mutex_lock() bug ??

Post by Casper H.S. Dik - Network Security Engine » Mon, 04 Sep 2000 17:51:46


[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


>I wrote the following little piece of code expecting it not to work
>since I thought only the thread that locked a mutex should be capable
>of unlocking it ( Mutex is ownership based ).
>But to mu surpsrise a mutex that was locked in main() could be unlocked
>by a spawned thread. Is this a bug in solaris implementation, or did I
>miss something.

For efficiency reasons, there is little or no error checking in mutex code.
Error checkign makes it many times more expensive.

There are speciail error checking mutexes in newer Solaris releases
that catch this but are more expensive.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

pthread_mutex_lock() bug ??

Post by son.. » Thu, 07 Sep 2000 09:58:03





> [[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


> >Thanks jrjnks for responding.
> >The 4 sttribute types you mentioned are listed under
> >pthread_mutexattr_settype() when I searched the web. But I could not
> >find them in my Solaris 2.6. I suspect they are 2.7 additions.
> >My 2.6 manual says pthread_mutex_unlock() returns EPERM if it is not
> >the owner of the lock, which is exactly the bahavior I fail to see,
> >forcing me to think this is a bug. But because Solaris is Solaris, I
m
> >a bit hesitant about calling foul. Because I could have missed
> >something.

> Which manual page is that?

> I can't find a reference to EPERM on a 2.6 system around here.

Hi Casper:
Thanks for pointing it out. I had made a mistake. I was working at a
Solaris 2.6 machine while looking at an older Solaris 2.5 Answerbook.
To my surprise 2.6 man pages do not specify an EPERM return value
though they make comments like "only the thread that locked a mutex can
unlock it" in man pthread_mutex_unlock.
My guess is that 2.5 and 2.6 had a bug but rather than fixing it in
2.6, they just deleted the EPERM part from the RETURN part of the
manual.
-------------------------------------------
Let me also reply to Andrew since his post is somehow not showing up in
the group ( I got an e-mail copy )
Andrew>It's your responsibility, by default, to make sure that only the
Andrew>thread that locks a mutex tries to unlock it. Otherwise the
Andrew>behaviour is undefined.
Not really POSIX ensures that implementation will let only the locked
thread to unlock it. This is acknowledge by solaris as well in
their "only the thread that locked a mutex can unlock it" phrase. I
also read this in Kleiman et. al 's "Programming with threads".

Andrew>If you want mutex locking to be error-checked, you need to
Andrew>create the mutex with the PTHREAD_MUTEX_ERRORCHECK type
attribute.
PTHREAD_MUTEX_ERRORCHECK is a type of teh mutex. Though I m not sure I
suspect this was not there in the initial standard ( Both my books on
pthreads do not make any mention of it ). Solaris did not have a
pthread_mutexattr_settype() interface till 2.7 ( or 2.8 ??. It
definitely wasn t there till 2.6 ). Instead this was the default
behavior as per the man pages.

Andrew>p.s. given that your code didn't contain any error checking, how
Andrew>exactly were you expecting it not to work?

see the above

Quote:> Casper
> --
> Expressed in this posting are my opinions.  They are in no way related
> to opinions held by my employer, Sun Microsystems.
> Statements on Sun products included here are not gospel and may
> be fiction rather than truth.

Sent via Deja.com http://www.deja.com/
Before you buy.
 
 
 

pthread_mutex_lock() bug ??

Post by Casper H.S. Dik - Network Security Engine » Thu, 07 Sep 2000 18:32:12


[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


>Thanks for pointing it out. I had made a mistake. I was working at a
>Solaris 2.6 machine while looking at an older Solaris 2.5 Answerbook.
>To my surprise 2.6 man pages do not specify an EPERM return value
>though they make comments like "only the thread that locked a mutex can
>unlock it" in man pthread_mutex_unlock.
>My guess is that 2.5 and 2.6 had a bug but rather than fixing it in
>2.6, they just deleted the EPERM part from the RETURN part of the
>manual.

No, not a bug.  This is completely intentional.

Mutexes require some expensive bus operations; if you do error
checking on unlock you suddenly require more of those expensive operations, so
mutex_unlock becomes a *lot* slower.

Quote:>Not really POSIX ensures that implementation will let only the locked
>thread to unlock it. This is acknowledge by solaris as well in
>their "only the thread that locked a mutex can unlock it" phrase. I
>also read this in Kleiman et. al 's "Programming with threads".

You should really read this as "you're not allowed to do so
but if you do all bets are off"

Quote:>Andrew>If you want mutex locking to be error-checked, you need to
>Andrew>create the mutex with the PTHREAD_MUTEX_ERRORCHECK type
>attribute.
>PTHREAD_MUTEX_ERRORCHECK is a type of teh mutex. Though I m not sure I
>suspect this was not there in the initial standard ( Both my books on
>pthreads do not make any mention of it ). Solaris did not have a
>pthread_mutexattr_settype() interface till 2.7 ( or 2.8 ??. It
>definitely wasn t there till 2.6 ). Instead this was the default
>behavior as per the man pages.

All comes clear when you read the unlock page in S7:

     If the mutex type is  PTHREAD_MUTEX_NORMAL, deadlock  detec-
     tion  is not provided. Attempting to relock the mutex causes
     deadlock. If a thread attempts to unlock a mutex that it has
     not  locked or a mutex which is unlocked, undefined behavior
     results.

     If the mutex type is  PTHREAD_MUTEX_ERRORCHECK,  then  error
     checking is provided. If a thread attempts to relock a mutex
     that it has already locked, an error will be returned. If  a
     thread  attempts to unlock a mutex that it has not locked or
     a mutex which is unlocked, an error will be returned.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

pthread_mutex_lock() bug ??

Post by Dave Butenho » Thu, 07 Sep 2000 21:20:50






> > [[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


> > >Thanks jrjnks for responding.
> > >The 4 sttribute types you mentioned are listed under
> > >pthread_mutexattr_settype() when I searched the web. But I could not
> > >find them in my Solaris 2.6. I suspect they are 2.7 additions.
> > >My 2.6 manual says pthread_mutex_unlock() returns EPERM if it is not
> > >the owner of the lock, which is exactly the bahavior I fail to see,
> > >forcing me to think this is a bug. But because Solaris is Solaris, I
> m
> > >a bit hesitant about calling foul. Because I could have missed
> > >something.

> > Which manual page is that?

> > I can't find a reference to EPERM on a 2.6 system around here.

> Hi Casper:
> Thanks for pointing it out. I had made a mistake. I was working at a
> Solaris 2.6 machine while looking at an older Solaris 2.5 Answerbook.
> To my surprise 2.6 man pages do not specify an EPERM return value
> though they make comments like "only the thread that locked a mutex can
> unlock it" in man pthread_mutex_unlock.
> My guess is that 2.5 and 2.6 had a bug but rather than fixing it in
> 2.6, they just deleted the EPERM part from the RETURN part of the
> manual.
> -------------------------------------------
> Let me also reply to Andrew since his post is somehow not showing up in
> the group ( I got an e-mail copy )
> Andrew>It's your responsibility, by default, to make sure that only the
> Andrew>thread that locks a mutex tries to unlock it. Otherwise the
> Andrew>behaviour is undefined.
> Not really POSIX ensures that implementation will let only the locked
> thread to unlock it. This is acknowledge by solaris as well in
> their "only the thread that locked a mutex can unlock it" phrase. I
> also read this in Kleiman et. al 's "Programming with threads".

No, you're misunderstanding POSIX. POSIX says that YOU, the application
developer, are not allowed to unlock a mutex you do not own. The
implementation IS ALLOWED TO (but need not) detect and report YOUR error by
returning EPERM.

Andrew Gierth was absolutely correct. The obligation is entirely on you. No
specific behavior is required of the implementation. Correct code does not
unlock the mutex from a thread that didn't lock it, and the effect of this
application error on the behavior of the process is not defined by POSIX.

This is why The Single UNIX Specification, Version 2 (aka UNIX 98) does not
specify the meaning of the "default mutex type" symbol. (This was actually
one of the few issues in the development of the specification where I was
wrong.) I argued that it would not be legal for an implementation to make
"recursive" the default mutex type, because the behavior is substantially
different in ways the application can detect. Eventually, though, I was
made to realize that the differences could be detected only by BROKEN
applications. Because the semantics of "default mutex" are not defined to
include the ability to re-lock a mutex from the owning thread, any
application that does this is wrong -- and no less wrong because the mutex
happens to be "recursive". The behavior of the erroneous application is
undefined, and there's nothing really worse about the behavior if the mutex
happens to be recursive. (An application designed for that particular
platform might "correctly", but not "portably", depend on the fact that the
default mutex is recursive -- but it'd be really bad design.)

The application is 100% responsible for correctness. The implementation may
help detect errors; but whether it does or not, it's the application that's
broken.

Quote:> Andrew>If you want mutex locking to be error-checked, you need to
> Andrew>create the mutex with the PTHREAD_MUTEX_ERRORCHECK type
> attribute.
> PTHREAD_MUTEX_ERRORCHECK is a type of teh mutex. Though I m not sure I
> suspect this was not there in the initial standard ( Both my books on
> pthreads do not make any mention of it ). Solaris did not have a
> pthread_mutexattr_settype() interface till 2.7 ( or 2.8 ??. It
> definitely wasn t there till 2.6 ). Instead this was the default
> behavior as per the man pages.

> Andrew>p.s. given that your code didn't contain any error checking, how
> Andrew>exactly were you expecting it not to work?

> see the above

You're arguing from a flawed assumption. You're deliberately doing
something wrong. You are of course justified in suggesting that the
implementation could have helped you to discover the application error --
but you also have to realize that the standard does not make any such
requirements. In terms of standards conformance, the implementation is not
at fault here, only your expectations.

Of course, "debug friendly" libraries are nice, and can help a lot during
development. However, it's complicated and difficult to maintain separate
production and debug libraries, and putting some times of error checking
(including this) into production thread libraries can be unreasonably and
unjustifiably expensive.

And, in any case, the implementation could have "helped" only by returning
an error code, for which you're not checking. You would have ignored the
only help it could offer!


| Compaq Computer Corporation   http://members.aol.com/drbutenhof |
| 110 Spit Brook Rd ZKO2-3/Q18, Nashua NH 03062-2698              |
\--------[ http://www.awl.com/cseng/titles/0-201-63392-2/ ]-------/

 
 
 

pthread_mutex_lock() bug ??

Post by David Schwart » Fri, 08 Sep 2000 02:11:32



> And, in any case, the implementation could have "helped" only by returning
> an error code, for which you're not checking. You would have ignored the
> only help it could offer!

        Actually, it could have helped by causing his buggy application to
crash.

        DS

 
 
 

pthread_mutex_lock() bug ??

Post by son.. » Fri, 08 Sep 2000 02:53:55








> > > [[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


> > > >Thanks jrjnks for responding.
> > > >The 4 sttribute types you mentioned are listed under
> > > >pthread_mutexattr_settype() when I searched the web. But I could
not
> > > >find them in my Solaris 2.6. I suspect they are 2.7 additions.
> > > >My 2.6 manual says pthread_mutex_unlock() returns EPERM if it is
not
> > > >the owner of the lock, which is exactly the bahavior I fail to
see,
> > > >forcing me to think this is a bug. But because Solaris is
Solaris, I
> > m
> > > >a bit hesitant about calling foul. Because I could have missed
> > > >something.

> > > Which manual page is that?

> > > I can't find a reference to EPERM on a 2.6 system around here.

> > Hi Casper:
> > Thanks for pointing it out. I had made a mistake. I was working at a
> > Solaris 2.6 machine while looking at an older Solaris 2.5
Answerbook.
> > To my surprise 2.6 man pages do not specify an EPERM return value
> > though they make comments like "only the thread that locked a mutex
can
> > unlock it" in man pthread_mutex_unlock.
> > My guess is that 2.5 and 2.6 had a bug but rather than fixing it in
> > 2.6, they just deleted the EPERM part from the RETURN part of the
> > manual.
> > -------------------------------------------
> > Let me also reply to Andrew since his post is somehow not showing
up in
> > the group ( I got an e-mail copy )
> > Andrew>It's your responsibility, by default, to make sure that only
the
> > Andrew>thread that locks a mutex tries to unlock it. Otherwise the
> > Andrew>behaviour is undefined.
> > Not really POSIX ensures that implementation will let only the
locked
> > thread to unlock it. This is acknowledge by solaris as well in
> > their "only the thread that locked a mutex can unlock it" phrase. I
> > also read this in Kleiman et. al 's "Programming with threads".

> No, you're misunderstanding POSIX. POSIX says that YOU, the
application
> developer, are not allowed to unlock a mutex you do not own. The
> implementation IS ALLOWED TO (but need not) detect and report YOUR
error by
> returning EPERM.

> Andrew Gierth was absolutely correct. The obligation is entirely on
you. No
> specific behavior is required of the implementation. Correct code
does not
> unlock the mutex from a thread that didn't lock it, and the effect of
this
> application error on the behavior of the process is not defined by
POSIX.

> This is why The Single UNIX Specification, Version 2 (aka UNIX 98)
does not
> specify the meaning of the "default mutex type" symbol. (This was
actually
> one of the few issues in the development of the specification where I
was
> wrong.) I argued that it would not be legal for an implementation to
make
> "recursive" the default mutex type, because the behavior is
substantially
> different in ways the application can detect. Eventually, though, I
was
> made to realize that the differences could be detected only by BROKEN
> applications. Because the semantics of "default mutex" are not
defined to
> include the ability to re-lock a mutex from the owning thread, any
> application that does this is wrong -- and no less wrong because the
mutex
> happens to be "recursive". The behavior of the erroneous application
is
> undefined, and there's nothing really worse about the behavior if the
mutex
> happens to be recursive. (An application designed for that particular
> platform might "correctly", but not "portably", depend on the fact
that the
> default mutex is recursive -- but it'd be really bad design.)

> The application is 100% responsible for correctness. The
implementation may
> help detect errors; but whether it does or not, it's the application
that's
> broken.

Ah yesterday only I was searching for the specs for the default type of
the mutex ( w.r.t. it s type ). I could not find any. So the conclusion
is that it s is OK for an implementation to have whatever behavior it
wants for a mutex. As Casper pointed out earlier Solaris - due to the
extra expence incurred - decided to make the default as "error
unchecked". Since they did not have any interface to set the type, they
left it to the programmer to ensure that only the locked thread will
ever unlock the mutex. I can forgive the vagueness in their man pages
for teh "only the thread that locked a mutex can unlock it"  phrase.

Thanks every body for clarification
Sony

- Show quoted text -

> > Andrew>If you want mutex locking to be error-checked, you need to
> > Andrew>create the mutex with the PTHREAD_MUTEX_ERRORCHECK type
> > attribute.
> > PTHREAD_MUTEX_ERRORCHECK is a type of teh mutex. Though I m not
sure I
> > suspect this was not there in the initial standard ( Both my books
on
> > pthreads do not make any mention of it ). Solaris did not have a
> > pthread_mutexattr_settype() interface till 2.7 ( or 2.8 ??. It
> > definitely wasn t there till 2.6 ). Instead this was the default
> > behavior as per the man pages.

> > Andrew>p.s. given that your code didn't contain any error checking,
how
> > Andrew>exactly were you expecting it not to work?

> > see the above

> You're arguing from a flawed assumption. You're deliberately doing
> something wrong. You are of course justified in suggesting that the
> implementation could have helped you to discover the application
error --
> but you also have to realize that the standard does not make any such
> requirements. In terms of standards conformance, the implementation
is not
> at fault here, only your expectations.

> Of course, "debug friendly" libraries are nice, and can help a lot
during
> development. However, it's complicated and difficult to maintain
separate
> production and debug libraries, and putting some times of error
checking
> (including this) into production thread libraries can be unreasonably
and
> unjustifiably expensive.

> And, in any case, the implementation could have "helped" only by
returning
> an error code, for which you're not checking. You would have ignored
the
> only help it could offer!


> | Compaq Computer Corporation   http://members.aol.com/drbutenhof |
> | 110 Spit Brook Rd ZKO2-3/Q18, Nashua NH 03062-2698              |
> \--------[ http://www.awl.com/cseng/titles/0-201-63392-2/ ]-------/

Sent via Deja.com http://www.deja.com/
Before you buy.
 
 
 

1. SIGSEGV in pthread_mutex_lock in RedHat 7.2 gcc 2.95.3

Complete error message and backtrace is below

I'm porting a working program from Linux 8.0 and have a case where
propagating an exception that is covered by a try {} catch{}
a couple of levels up the stack leads to the mentioned SIGSEGV.
This is on RedHat Linux 7.2 on IBM zSeries.

I also have RedHat Linux 7.2 on Intel with gcc 2.96 and this
works correctly.

Any ideas? Might this be the compiler?

Jim
____________________________________________________________________
Program received signal SIGSEGV, Segmentation fault.
0x403eb2d6 in __pthread_mutex_lock (mutex=0x410) at mutex.c:99
99      mutex.c: No such file or directory.
         in mutex.c
Current language:  auto; currently c
(gdb) backtrace
#0  0x403eb2d6 in __pthread_mutex_lock (mutex=0x410) at mutex.c:99
#1  0x402da138 in __libc_free (mem=0x410) at malloc.c:3152
#2  0x00410d46 in __builtin_vec_delete (ptr=0x410) at
../../gcc/cp/new2.cc:62
#3  0x00416a36 in SmException::~SmException (this=0x7ffff988,
__in_chrg=2) at src/cpp/SmException_c.h:65
#4  0x0040e19e in main (argc=1, argv=0x7ffffad4) at src/sample/sample.cpp:21

2. Will Linux run on this hardware?

3. why is pthread_mutex_lock a wrapper?

4. FAX modem under samba

5. pthread_mutex_lock() problem

6. boot virus after 6.1 install!!!

7. thread waiting on pthread_mutex_lock() forever (for mutex of type PTHREAD_MUTEX_ERRORCHECK)

8. FreeBSD 2.2.7 encrytption

9. pthread_mutex_lock-dual processor-Address out of bounds

10. pthread_mutex_lock fails

11. pthread_mutex_lock() question

12. crashes from pthread_mutex_lock ()

13. pthread_mutex_lock() causes vfork call?!