Paul Smedley | 1 Jan 10:30 2006

calloc causing SIGSEGV?

Hi All and Happy New Year!

Hope everyone had a big one - we certainly did :)

Have been playing with mplayer over the last day or two, latest source
from cvs compiles pretty easily, but is giving a SIGSEGV on startup 
after a calloc call:
Killed by SIGSEGV
pid=0x0bd7 ppid=0x0bd6 tid=0x0001 slot=0x00ee pri=0x0200 mc=0x0001
E:\DEV\MPLAYER-CVS\MAIN\MPLAYER.EXE
MPLAYER 0:000170de
cs:eip=005b:000270de      ss:esp=0053:0082eb50      ebp=00856a30
 ds=0053      es=0053      fs=150b      gs=0000     efl=00212246
eax=0000000a ebx=000111e2 ecx=cccccccc edx=17ff803c edi=00d476e0 
esi=008313f8
Process dumping was disabled, use DUMPPROC to enable it.

The call in question is: 
  co = (m_config_option_t*)calloc(1,sizeof(m_config_option_t) + 
arg->type->size);

Are there any common reasons for a calloc to cause a SIGSEGV - stack 
space or something like that?

--

-- 
Cheers,

Paul.
knut st. osmundsen | 2 Jan 22:16 2006
Picon

Re: calloc causing SIGSEGV?

Paul Smedley wrote:
> Hi All and Happy New Year!
> 
> Hope everyone had a big one - we certainly did :)

Happy New Year Paul!

> Have been playing with mplayer over the last day or two, latest source
> from cvs compiles pretty easily, but is giving a SIGSEGV on startup 
> after a calloc call:
> Killed by SIGSEGV
> pid=0x0bd7 ppid=0x0bd6 tid=0x0001 slot=0x00ee pri=0x0200 mc=0x0001
> E:\DEV\MPLAYER-CVS\MAIN\MPLAYER.EXE
> MPLAYER 0:000170de
> cs:eip=005b:000270de      ss:esp=0053:0082eb50      ebp=00856a30
>  ds=0053      es=0053      fs=150b      gs=0000     efl=00212246
> eax=0000000a ebx=000111e2 ecx=cccccccc edx=17ff803c edi=00d476e0 
> esi=008313f8
> Process dumping was disabled, use DUMPPROC to enable it.
> 
> The call in question is: 
>   co = (m_config_option_t*)calloc(1,sizeof(m_config_option_t) + 
> arg->type->size);
> 
> Are there any common reasons for a calloc to cause a SIGSEGV - stack 
> space or something like that?

it looks like there is sufficient with stack, but it's difficult to say 
that without looking at the binary (the stack object/segment is usually 
the 2nd one). A common reason why calloc crashes is heap corruptions, 
(Continue reading)

Paul Smedley | 3 Jan 12:06 2006

Re: calloc causing SIGSEGV?

Hi Knut!

On Mon, 2 Jan 2006 21:16:12 UTC, "knut st. osmundsen" 
<bird <at> anduin.net> wrote:

> Paul Smedley wrote:
> > Have been playing with mplayer over the last day or two, latest source
> > from cvs compiles pretty easily, but is giving a SIGSEGV on startup 
> > after a calloc call:
> > Killed by SIGSEGV
> > pid=0x0bd7 ppid=0x0bd6 tid=0x0001 slot=0x00ee pri=0x0200 mc=0x0001
> > E:\DEV\MPLAYER-CVS\MAIN\MPLAYER.EXE
> > MPLAYER 0:000170de
> > cs:eip=005b:000270de      ss:esp=0053:0082eb50      ebp=00856a30
> >  ds=0053      es=0053      fs=150b      gs=0000     efl=00212246
> > eax=0000000a ebx=000111e2 ecx=cccccccc edx=17ff803c edi=00d476e0 
> > esi=008313f8
> > Process dumping was disabled, use DUMPPROC to enable it.
> > 
> > The call in question is: 
> >   co = (m_config_option_t*)calloc(1,sizeof(m_config_option_t) + 
> > arg->type->size);
> > 
> > Are there any common reasons for a calloc to cause a SIGSEGV - stack 
> > space or something like that?
> 
> it looks like there is sufficient with stack, but it's difficult to say 
> that without looking at the binary (the stack object/segment is usually 
> the 2nd one). A common reason why calloc crashes is heap corruptions, 
> and that's generally difficult to find without suitable tools. I could 
(Continue reading)

Paul Smedley | 5 Jan 03:52 2006

Select() problem

Hi All,
In trying Openldap I've found that the daemon fails due to select.

In this case it doesn't appear to be trying to select() on a socket..

I tried compiling the example select() code from 
http://www.die.net/doc/linux/man/man2/select.2.html, ie:
#include <stdio.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>

int
main(void) {
    fd_set rfds;
    struct timeval tv;
    int retval;

    /* Watch stdin (fd 0) to see when it has input. */
    FD_ZERO(&rfds);
    FD_SET(0, &rfds);
    /* Wait up to five seconds. */
    tv.tv_sec = 5;
    tv.tv_usec = 0;

    retval = select(1, &rfds, NULL, NULL, &tv);
    /* Don't rely on the value of tv now! */

    if (retval == -1)
        perror("select()");
(Continue reading)

Dave Yeo | 5 Jan 05:22 2006

Re: Select() problem

On Thu, 5 Jan 2006 02:52:18 +0000 (UTC), Paul Smedley wrote:

>
>... and this fails in the same way as Openldap - namely with errno = 
>Invalid argument

With bsdselect it fails with
R:\tmp>testbsd.exe
bsdselect(): Socket operation on non-socket

You might want to look in sys/select.h
Dave
Paul Smedley | 5 Jan 10:16 2006

Re: Select() problem

Hi Dave,

On Thu, 5 Jan 2006 04:22:42 UTC, "Dave Yeo" <dave_yeo <at> paralynx.com> 
wrote:
> On Thu, 5 Jan 2006 02:52:18 +0000 (UTC), Paul Smedley wrote:
> 
> >... and this fails in the same way as Openldap - namely with errno = 
> >Invalid argument
> 
> With bsdselect it fails with
> R:\tmp>testbsd.exe
> bsdselect(): Socket operation on non-socket

Hmmmm now that I changed openldap to use bsdselect() I also get 
"Socket operation on non-socket" :(

Any known ways to workaround these limitations?

> You might want to look in sys/select.h
Will do.

--

-- 
Cheers,

Paul.
Knut St. Osmundsen | 5 Jan 15:23 2006
Picon

Re: Re: Select() problem

Paul Smedley wrote:
> Hi Dave,
> 
> On Thu, 5 Jan 2006 04:22:42 UTC, "Dave Yeo" <dave_yeo <at> paralynx.com> 
> wrote:
> 
>>On Thu, 5 Jan 2006 02:52:18 +0000 (UTC), Paul Smedley wrote:
>>
>>
>>>... and this fails in the same way as Openldap - namely with errno = 
>>>Invalid argument
>>
>>With bsdselect it fails with
>>R:\tmp>testbsd.exe
>>bsdselect(): Socket operation on non-socket
> 
> 
> Hmmmm now that I changed openldap to use bsdselect() I also get 
> "Socket operation on non-socket" :(
> 
> Any known ways to workaround these limitations?

You cannot select on anything but sockets atm.
There is not need for using bsdselect(), select() will call bsdselect() 
if you pass it only sockets. If you pass it other stuff, well, then it 
will fail as you just saw.

Kind Regards,
  knut
(Continue reading)


Gmane