Avast WEBforum
Business Products => Avast Business => Avast Business for Linux => Topic started by: zilog on February 06, 2009, 04:31:22 PM
-
Hallo,
if you like obscure and uncanny platforms, maybe you would try latest betas of avastengine/avastdaemon (functionally equivalent with Linux's counterparts) for SunOS/Solaris - available here:
http://public.avast.com/~cimbal/Solaris/
In case of any problem, let me know. If you think it works fine for you, let me know too :).
Regards,
pc
-
Perhaps it would be a good idea to post this on an opensolaris/solaris forum to get more testers.
-
Perhaps it would be a good idea to post this on an opensolaris/solaris forum to get more testers.
Hallo,
I'll try this forum, thanks.
Regards,
pc
-
Have been using this update - avastcmd crashes and gives me a core dump on some pdf files (it happens each time I try it). 100s of other files parse correctly. I am running on a SunFire V210 sparc Solaris 10 5/08.
Unfortunately I cannot send you the file it complains about (MemeoAutoBackuplicense.pdf - it is on my new Western Digital "My Book" 1T external USB hard disc) because it is on a funny network.
Julian
-
Have been using this update - avastcmd crashes and gives me a core dump on some pdf files (it happens each time I try it). 100s of other files parse correctly. I am running on a SunFire V210 sparc Solaris 10 5/08.
Unfortunately I cannot send you the file it complains about (MemeoAutoBackuplicense.pdf - it is on my new Western Digital "My Book" 1T external USB hard disc) because it is on a funny network.
Julian
Hallo, thanks for the report!
But, the PDF parsing part is well hidden inside x86 asembly code, which runs in a virtual environment inside avast - is it possible to reproduce the bug using "truss" utility, or "dtrace"? it could be vital to at least see, where it crashes (when we cannot test it on the very same file).
thanks in advance,
regards,
pc
-
This output of truss is typed in, so be gentle with my mistakes:
/1; fpathconf(6, _PC_NAME_MAX) = 8
/1: lstat64("/rmdisk/unnamed_rmdisk/wd_windows_tools/EULA/ENG/MemeoAutoSynclicense.pdf", 0xFFBFCFC8) = 0
/1: Incurred fault #5, FLTACCESS %pc = 0xFDDD49B4
/1: siginfo: SIGBUS BUS_ADRALN addr=0x666D9676
/1: Received signal #10, SIGBUS [caught]
/1: setcontext(0xFFBFC938)
/1: Incurred fault #5, FLTACCESS %pc = 0xFDDD49B4
/1: siginfo: SIGBUS BUS_ADRALN addr=0x666D9676
/1: Received signal #10, SIGBUS [default]
and there it is dead.
If I do this file on its own, there are no problems.
However I can also get it to do this (if I run over the same directory structure, but at a higher starting point)
/1; fpathconf(6, _PC_NAME_MAX) = 8
/1: lstat64("/rmdisk/unnamed_rmdisk/wd_windows_tools/EULA/ENG/MemeoAutoSynclicense.pdf", 0xFFBFD2F8) = 0
/1: Incurred fault #6, FLTBOUNDS %pc = 0xFDDD4D58
/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x0000001C
/1: Received signal #11, SIGSEGV [caught]
/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x0000001C
/1: setcontext (0xFFBFCC08)
/1: Incurred fault #6, FLTBOUNDS %pc = 0xFDDD4D58
/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x0000001C
/1: Received signal #11, SIGSEGV [caught]
/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x0000001C
which is also quite fatal.
Julian
-
This output of truss is typed in, so be gentle with my mistakes:
/1; fpathconf(6, _PC_NAME_MAX) = 8
/1: lstat64("/rmdisk/unnamed_rmdisk/wd_windows_tools/EULA/ENG/MemeoAutoSynclicense.pdf", 0xFFBFCFC8) = 0
/1: Incurred fault #5, FLTACCESS %pc = 0xFDDD49B4
/1: siginfo: SIGBUS BUS_ADRALN addr=0x666D9676
/1: Received signal #10, SIGBUS [caught]
/1: setcontext(0xFFBFC938)
/1: Incurred fault #5, FLTACCESS %pc = 0xFDDD49B4
/1: siginfo: SIGBUS BUS_ADRALN addr=0x666D9676
/1: Received signal #10, SIGBUS [default]
and there it is dead.
If I do this file on its own, there are no problems.
However I can also get it to do this (if I run over the same directory structure, but at a higher starting point)
/1; fpathconf(6, _PC_NAME_MAX) = 8
/1: lstat64("/rmdisk/unnamed_rmdisk/wd_windows_tools/EULA/ENG/MemeoAutoSynclicense.pdf", 0xFFBFD2F8) = 0
/1: Incurred fault #6, FLTBOUNDS %pc = 0xFDDD4D58
/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x0000001C
/1: Received signal #11, SIGSEGV [caught]
/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x0000001C
/1: setcontext (0xFFBFCC08)
/1: Incurred fault #6, FLTBOUNDS %pc = 0xFDDD4D58
/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x0000001C
/1: Received signal #11, SIGSEGV [caught]
/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x0000001C
which is also quite fatal.
Julian
Hallo,
does look like an align problem - thus, best I could do now is to run the debug version over the file. Is it possible to get the particular file?
Or, can you check whether it's the file contents, that matters? (would some dummy file, placed there instead, cause crash too?)
regards,
pc
-
The Solaris version installation changes the owner and permissions of /var/tmp. It's a problem because this directory is used by a lot of processes and commands and must have write permission for all.
It changes this directories too:
drwxr-xr-x 70 bin bin 5632 Jun 29 17:51 /etc
drwxr-xr-x 2 bin bin 1536 Jun 29 17:50 /etc/default
drwxr-xr-x 2 bin bin 1536 Jun 29 17:50 /etc/init.d
drwxr-xr-x 40 bin bin 1024 Nov 19 2008 /usr/
drwxr-xr-x 4 bin bin 16384 Jun 29 17:51 /usr/bin
drwxr-xr-x 5 bin bin 8192 Jun 29 17:50 /usr/sbin
drwxr-xr-x 39 bin bin 2560 Nov 19 2008 /usr/share
drwxr-xr-x 5 bin bin 512 Jun 29 17:51 /usr/share/doc
drwxr-xr-x 193 bin bin 4096 Nov 19 2008 /usr/share/man
drwxr-xr-x 46 bin bin 1024 Nov 19 2008 /var
drwxr-xr-x 4 bin bin 512 Jun 29 17:51 /var/lib
drwxr-xr-x 6 bin bin 512 Jun 29 17:50 /var/log
drwxr-xr-x 6 bin bin 1407 Jun 29 17:50 /var/run
(Before Installation)
drwxr-xr-x 70 root sys 5632 Mar 10 21:24 /etc
drwxr-xr-x 2 root sys 1536 Mar 10 21:24 /etc/default
drwxr-xr-x 2 root sys 1536 Nov 11 2008 /etc/init.d
drwxr-xr-x 40 root sys 1024 Nov 11 2008 /usr/
drwxr-xr-x 5 root bin 15360 Dec 17 2008 /usr/bin
drwxr-xr-x 5 root bin 8192 Nov 11 2008 /usr/sbin
drwxr-xr-x 22 root sys 2048 Nov 11 2008 /usr/share
drwxr-xr-x 3 root other 512 Jan 16 2007 /usr/share/doc
drwxr-xr-x 193 root bin 4096 Nov 11 2008 /usr/share/man
drwxr-xr-x 46 root sys 1024 Nov 11 2008 /var
drwxr-xr-x 3 root other 512 Nov 11 2008 /var/lib
drwxr-xr-x 5 root sys 512 Nov 11 2008 /var/log
drwxr-xr-x 5 root sys 1415 May 18 23:03 /var/run
-
One question. What is the task of avastd daemon?
I have the daemon started on a linux (debian) machine and it don't scanning anything.
-
I can't rerun this (I have been away and the disc arrangements have changed).
Howerver, the logs show the program counter - so you should be able to work out which instructions cause the bus error (misaligned data) and segmentation fault (reference to memory location zero).
I wonder if the port is assuming that 32 bit data can be read on 16 bit word boundaries. Intel CPUs retry misaligned data automatically (taking a performance hit). SPARC CPUs crash with a bus error.
Julian
PS: If I can find a core dump, I will send you the stack trace.
-
I can't rerun this (I have been away and the disc arrangements have changed).
Howerver, the logs show the program counter - so you should be able to work out which instructions cause the bus error (misaligned data) and segmentation fault (reference to memory location zero).
I wonder if the port is assuming that 32 bit data can be read on 16 bit word boundaries. Intel CPUs retry misaligned data automatically (taking a performance hit). SPARC CPUs crash with a bus error.
Julian
PS: If I can find a core dump, I will send you the stack trace.
Hallo, by the way, the build has changed - the binaries at mentioned url now contain latest build.
program counter isn't very useful here, because PDF is manipulated from inside of dynamically-translated code environment - such code is created on demand, dynamically, contains no symbols and without the culprit-file it's nearly NP-problem to get the backtrace.
regards,
pc
-
> I wonder if the port is assuming that 32 bit data can be read on 16 bit word boundaries. Intel CPUs retry misaligned data automatically (taking a performance hit). SPARC CPUs crash with a bus error.
of course, ALL accesses that might be on unaligned place, are translated into smaller, aligned accesses, in the SPARC build. But, debugging without the problematic data isn't easy, in this case, because the behavior is data-dependent.
regards,
pc
-
Coredump in avastcmd. The core file is very small (52 bytes). In the process log I can see:
EMULATION: Fault in code outside emulation layer. Aborting.
-
Coredump in avastcmd. The core file is very small (52 bytes). In the process log I can see:
EMULATION: Fault in code outside emulation layer. Aborting.
Hallo,
what i need is the file that caused it when it was scanned. is it possible to get it?
hint: the last line, written by the crashed scan, is the file right before the bad one. use ls or find to get the ordering, and identify what was the subsequent bad file. then,. send it to me (preferable passwd-zipped). thanks.
note: it's usually bigger problem in general, affecting also avast for Windows, but on Solaris, the environment is more sensitive for those bugs, because all the live code in vps is dynamically translated on the fly.
regards,
pc
-
It will be great, imagine not only those marvelous SPARC machines hungrily crunching, but also a lot of home users running their own Solaris/x86 Solaris 10 running in 64 bits with AMD opteron processors could even fly.
Hallo, Solaris 10 on x86 is supported, just try it :).
regards,
pc