Segmentation violation in 2.8

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Unpack the attached tar archive.
2. Put the files in the relevant dirs.
3. Start the web server.
4. Load the page in the browser.
5. Wait a few minutes. The crash should happen within 20-30 minutes.

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
+ moongoose-2.8
+ SUSE Linux Enterprise Desktop 10 SP1 (i586)

Please provide any additional information below.
+ GDB says:
*** Mongoose debug *** worker_thread: thread 0xb75d7ba0 exiting
[Thread -1218610272 (LWP 26015) exited]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1227002976 (LWP 26017)]
0xb7f033f0 in pthread_mutex_lock () from /lib/libpthread.so.0

Original issue reported on code.google.com by mats.car...@gmail.com on 13 Jul 2009 at 6:57

Attachments:

• BUG.gz

[GoogleCodeExporter]

Can't reproduce it on my MacOS (don't have any Linux at hands at the moment).
Could you build with -g and send both binary and core file, please?

Original comment by valenok on 19 Jul 2009 at 10:11

[GoogleCodeExporter]

I could not reproduce the crash on MacOS, by the way. It seems to be Linux 
specific.

Original comment by valenok on 19 Jul 2009 at 12:12

[GoogleCodeExporter]

I suspect you want an un-stripped binary, i.e. produced without the -s linking 
option?

Compiling with -g and linking with -s (strip) gives a binary that still crashes.
Skipping -s gives a binary that doesn't crash (at least not for the last 24h). 
Also,
it seems it's CPU-dependent; on my laptop the crashes occur, but on a 
stationary box
with the same OS it does not. The big difference is the CPU: The laptop has:

> cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 CPU         T7200  @ 2.00GHz
stepping        : 6
cpu MHz         : 1000.000
cache size      : 4096 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx lm constant_tsc pni 
monitor
ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips        : 3995.20

while the stationary box has:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz
stepping        : 6
cpu MHz         : 1596.000
cache size      : 4096 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni 
monitor
ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips        : 4803.99

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz
stepping        : 6
cpu MHz         : 1596.000
cache size      : 4096 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni 
monitor
ds_cpl vmx est tm2 cx16 xtpr lahf_lm
bogomips        : 4800.30

Since I'm not dependent on the resulting binary being very small, I think I'll 
stop
using the -s option to the linker. It looks like this would be a hard issue to 
solve,
and probably involves what gcc does for this particular CPU.

Original comment by mats.car...@gmail.com on 20 Jul 2009 at 11:10

[GoogleCodeExporter]

I still advise you to send non-stripped binary with the core file to me. This 
might
be a bug in the Mongoose core.

Original comment by valenok on 20 Jul 2009 at 11:33

[GoogleCodeExporter]

The non-stripped binary does not crash, so there is no core file. Did you mean 
that I
should send you the non-stripped binary together with the core file from the 
crash
with the stripped binary? I'll gladly send you (non-stripped-binary +
core-file-generated-by-stripped-binary) if you want them, but personally I 
can't see
that the combination would be useful.

Original comment by mats.car...@gmail.com on 21 Jul 2009 at 6:13

[GoogleCodeExporter]

Yeah, please send only stripped one (the one that crashes), and a core file.
Another thing you may try is to use different optimisation options.
Like, build with -O2 instead -Os.
Different compiler would also be worth trying.

Original comment by valenok on 21 Jul 2009 at 6:58

[GoogleCodeExporter]

Here they are.

Original comment by mats.car...@gmail.com on 21 Jul 2009 at 2:02

Attachments:

• FOO.tar.gz

[GoogleCodeExporter]

Could you sync to the head and try again, please?
I've submitted http://code.google.com/p/mongoose/source/detail?r=455
I was able to reproduce the crash on my Linux box, with that change the crash 
does
not appear although it is still not clear why.

Original comment by valenok on 23 Jul 2009 at 11:52

• Changed state: Accepted

[GoogleCodeExporter]

I've tested it overnight, and it looks good.

Original comment by mats.car...@gmail.com on 24 Jul 2009 at 4:56

[GoogleCodeExporter]

Original comment by valenok on 24 Jul 2009 at 8:08

• Changed state: Fixed

[GoogleCodeExporter]

Issue 95 has been merged into this issue.

Original comment by valenok on 2 May 2010 at 11:17

[GoogleCodeExporter]

I get almost the same error as the person who submitted Issue 95:

Unhandled exception at 0x0091b995 in server.exe: 0xC0000005: Access violation 
reading
location 0x00000454.

with the call stack:

server.exe!pthread_mutex_lock(void * * mutex=0x00000454)  Line 864 + 0x7 bytes  C
server.exe!worker_thread(mg_context * ctx=0x01d04328)  Line 4525 + 0xe bytes    C
kernel32.dll!75f04911()     
[Frames below may be incorrect and/or missing, no symbols loaded for 
kernel32.dll]   
ntdll.dll!7725e4b6()    
ntdll.dll!7725e489()

I compiled my code using Visual Studio 2008's cpp compiler, and I'm running 
Windows
Vista.

I only get this error maybe once every 5 runs, but it completely breaks my 
program
when it happens. Should this Issue still be considered fixed?

Original comment by ibwoo...@gmail.com on 3 Jun 2010 at 2:22

[GoogleCodeExporter]

Issue 156 has been merged into this issue.

Original comment by valenok on 25 Jun 2010 at 11:49

[GoogleCodeExporter]

I'd just like to add that this issue is still happening in Windows Vista for 
both 2.7 and 2.8.

Original comment by gatekil...@gmail.com on 30 Jul 2010 at 11:50

[GoogleCodeExporter]

It crashes for me to after running a while. I run Ubuntu 10.04 AMD64.

Original comment by goo...@vmlinux.org on 18 Aug 2010 at 2:32

[GoogleCodeExporter]

Update from me. I'm now running 2.6 with no problems so it seems to be 
something that was added in 2.7.

Original comment by gatekil...@gmail.com on 18 Aug 2010 at 2:51

[GoogleCodeExporter]

Thanks a lot! Have you been running 2.6 for a long?  I tried to download the 
latest sources with "hg", but the examples would not build anymore, so that was 
very disappointing.

Original comment by goo...@vmlinux.org on 18 Aug 2010 at 2:52

[GoogleCodeExporter]

I've been using 2.6 for a few weeks and only for local development of websites 
on Windows Vista Business Edition 32bit.

What's weird is that I was able to run 2.8 for the first full day of using it 
but then afterwards it would crash randomly. I don't remember any updates to 
the system on that day so I'm not sure what changed.

2.6 is running fine and does the job I need, I'm just putting my update out 
in-case it helps anyone.

Original comment by gatekil...@gmail.com on 18 Aug 2010 at 3:19