# [Solved]Subversion causes core in Apache

## lyallp

I have Apache 2.0.58-r2, with subversion 1.3.2-r4 and if I use WebSVN 1.61, I can peruse my repository.

If, however, I try browsing to http://localhost/svn/repos (my local repository), I find in my error_log

```
[Mon Jun 18 19:32:24 2007] [notice] Apache configured -- resuming normal operations

[Mon Jun 18 19:32:34 2007] [notice] child pid 739 exit signal Segmentation fault (11)

[Mon Jun 18 19:32:34 2007] [notice] child pid 741 exit signal Segmentation fault (11)

```

Additionally, if I try changing directory into a local working copy directory and doing a 'svn ls', I receive the same core dump.

Now, I would not mind so much except that I am stuffed if I can actually find the core file.

I have previously updated /etc/conf.d/rc to have 

```
RC_ULIMIT='-n 8192 -c unlimited'
```

as can be seen by 

```

root@lyalls-pc:etc

# ulimit -a

core file size          (blocks, -c) unlimited

data seg size           (kbytes, -d) unlimited

scheduling priority             (-e) 0

file size               (blocks, -f) unlimited

pending signals                 (-i) 16383

max locked memory       (kbytes, -l) 32

max memory size         (kbytes, -m) unlimited

open files                      (-n) 8192

pipe size            (512 bytes, -p) 8

POSIX message queues     (bytes, -q) 819200

real-time priority              (-r) 0

stack size              (kbytes, -s) 8192

cpu time               (seconds, -t) unlimited

max user processes              (-u) 16383

virtual memory          (kbytes, -v) unlimited

file locks                      (-x) unlimited

root@lyalls-pc:etc

# 
```

I have rebuilt subversion, then apache (and restarted apache)

I am a little low on ideas now. Any hints?

----------

## KifranKober

Hello, I have the same issue since the last subversion update (1.3.2-r3 -> 1.3.2-r4) with Apache 2.0.58-r2.

The only thing I could do was to comment SVN references in httpd.conf in order to let my other Apache apps work...

Any help would be much appreciated  :Smile: 

Thanks.

----------

## WildCoder

Hello,

I've got the same problem. The subversion client I upgraded on some machines work fine. but my subversion server is not working. I use the webdav connection. It seems that apache isn't answering at all. I tried to reverse neon and subversion using

```

emerge --oneshot =net-misc/neon-0.25.3 =subversion-1.3.2-r3

```

but all I get is

 *Quote:*   

> 
> 
> 09:27:00 (602.36 KB/s) - `/usr/portage/distfiles/neon-0.25.3.tar.gz' saved [730495]
> 
>  * checking ebuild checksums  ...                                      [ ok ]
> ...

 

is there an alternate way to go back to the previous version? Thanks for your help!

-WildCoder

----------

## srpape

Same problem. I just masked the current subversion and reemerged it, restarted apache and now it's working.

In /etc/portage/package.mask:

```

=dev-util/subversion-1.3.2-r4

```

----------

## WildCoder

Hello,

On my system to get it restarted I had to go back to an earlier version of neon and subversion like this:

```

emerge --unmerge neon

ebuild /usr/portage/net-misc/neon/neon-0.25.3.ebuild digest

emerge --oneshot '<net-misc/neon-0.26'

emerge --unmerge subversion

emerge --oneshot --nodep =dev-util/subversion-1.3.2-r3

```

the ebuild was because emerging neon kept on complainint that the file size was incorrect. I'm going to wait a while before attempting to upgrade subversion again. Maybe even wait for 1.4 to finally come out and then some more. But at least I know how to get back to the working version now.

-WildCoder

----------

## Meeuw

See this bug report:

https://bugs.gentoo.org/show_bug.cgi?id=182453

----------

## lyallp

Ok, will have to investigate further.

What I would really like to know is where are my core files?

If I can find them, I can start making headway to actually solving this.

I have 'searched' the entire filesystem looking for core.[0-9]+ and simple 'core', to no avail.

As per the ticket, I have 'upgraded' to ~x86 version, l have some configuration to do before I can report back.

----------

## Hu

A core file may not be saved if the dying process does not have permission to write to the location where the file should appear.  A common case of this would be a daemon that calls chdir("/") and changes to a non-root user, then crashes.  If you have not already, read How to get meaningful backtraces in Gentoo before continuing.

Your least invasive option is to attach gdb to the Apache process before it dies, then do the action which causes the crash.  Since Apache may have many children, you may need to attach one gdb to each of them to ensure that you catch the one which will die.  For a SIGSEGV, gdb should be able to break in and let you analyze the crash.  Once you have the process halted, you can use the command gcore filename to save a core image to filename for later analysis.

You could change /proc/sys/kernel/core_pattern to change the location and name of core files.  It can contain path information, so that all core files are forced to a single directory, such as /tmp.  This change affects all processes which dump core, and may confuse certain types of watchdogs, so be careful.

----------

## KifranKober

Hi,

As srpape, I added the following lines in /etc/portage/package.mask:

```

=dev-util/subversion-1.3.2-r4

=net-misc/neon-0.26.3

```

then re-emerged and everything worked fine...

Thanks a lot.

----------

## lyallp

Well, I simply moved to apache ~x86 and apache-tools ~x86

After configuration issues and having to rebuild subversion/php - I, too, am back on-line.

My package keywords is gradually filling with ~x86   :Very Happy: 

----------

## arantius

Bump.

Got almost the same thing.  Apache was working fine, but accessing my SVN repository would segfault every time, after an update world.

Mask "=dev-util/subversion-1.3.2-r4" and "=net-misc/neon-0.26.3", remove subversion and neon and apr-1 and re-emerge subversion: status good.

----------

## lyallp

I don't compile my programs with debugging symbols, the last time I tried, I ran out of disk space (I only have 4gb partitions and I was too exasperated to get LVM working, after about 6 retries, that is ancient history).

Well, I also figured out how to find the core dumps.

I have added some script to '/etc/conf.d/local.start'

```

#                                                                                                                                     

# I want all core files to appear somewhere, this was prompted by Apache core dumping                                                 

# and not having write permissions to the root directory to actually write the core                                                   

#  Written by Lyall Pearce, 21-06-2007                                                                                                

#                                                                                                                                     

if [ -f /proc/sys/kernel/core_pattern ]

then

    [ -f /tmp/cores ] && /bin/rm -f /tmp/cores

    [ ! -d /tmp/cores ] && /bin/mkdir -p /tmp/cores

    /bin/chmod ogu+rwx /tmp/cores

    echo "/tmp/cores/core-PID=%p+Program=%e+Who=%u+Group=%g" > /proc/sys/kernel/core_pattern

fi

```

I ensure that local is part of the startup using 

```
rc-update add local default
```

This way, nearly all my core files end up in the same, writable place (the only exceptions are the ones that are generated prior to 'local' starting)

----------

## pstamb

Had the same problem. 

Finally, the bug report link above has the most elegant solution. For the lazy readers:

```
emerge --sync

emerge subversion

```

Do the emerge step even if you already have subversion from an older install. The subversion version number may not change, but the file that will take care of the install will.

----------

## frameRATE

 *pstamb wrote:*   

> Had the same problem. 
> 
> Finally, the bug report link above has the most elegant solution. For the lazy readers:
> 
> ```
> ...

 

Don't forget

```
/etc/init.d/apache2 restart
```

Thanks for this, I had NO IDEA it would be subversion being the problem. Was scratching my head all weekend.

----------

## lyallp

It p*sses me off no end when people change the ebuilds without updating the version numbers.

I don't care how minor the change, change the version number, even just the r# part. Failure to do this results in problems being on-going for much longer than they need, as in this case.

I had a similar problem with the bash shell at one stage.

----------

