Description of problem: Running this command will cause a weird problem: [root@fab log]# rpm -E %{lua} Segmentation fault (core dumped) However this should not be happened as if I run this: [root@fab log]# rpm -E %{luaa} %{luaa} As you can see, it returns the input, but it seems that %{lua} is a special case. Version-Release number of selected component (if applicable): rpm-4.11.0.1-7.fc20
I can reproduce on f18 x86_64 # rpm -E %{lua} Segmentation fault (core dumped) # rpm -E %{optflags} -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
%{lua} is indeed special as its used to invoke rpm's embedded lua interpreter, eg: [pmatilai@localhost ~]$ rpm --eval "%{lua:print(1+2)}" 3 [pmatilai@localhost ~]$ And yes its reproducable all the way back to rpm 4.3.x where the embedded lua interpreter was introduced, its just missing some sanity checks. Will fix.
(In reply to Panu Matilainen from comment #2) > %{lua} is indeed special as its used to invoke rpm's embedded lua > interpreter, eg: > > [pmatilai@localhost ~]$ rpm --eval "%{lua:print(1+2)}" > 3 > [pmatilai@localhost ~]$ > > And yes its reproducable all the way back to rpm 4.3.x where the embedded > lua interpreter was introduced, its just missing some sanity checks. Will > fix. Thanks, it's my first time to know about that.
Fixed upstream now: http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=43a34e155432354454ba11b2d9decf86cfba26a6 Oh and thanks for reporting, its amazing how long bugs can stay dormant sometimes, close to decade in this case :)
Hmm, except that turns out to be not so good a fix as it behaves differently from other built-ins afterall. Anyway, just use a non-reserved macro name to avoid the issue, defining and using %{lua} for your own purposes is not going to work.
The segfault is fixed in rpm-4.11.1-0.rc2.1.fc20.
The segfault was fixed with commit 43a34e155432354454ba11b2d9decf86cfba26a6 but reverted here f173f747cda11e3f6778d2553fcb0db4b4e1d571 I think that the bug is open again now
(In reply to devzero2000 from comment #7) > The segfault was fixed with commit 43a34e155432354454ba11b2d9decf86cfba26a6 > but reverted here f173f747cda11e3f6778d2553fcb0db4b4e1d571 > > I think that the bug is open again now No. The initial fix was reverted and replaced with a better one.
I am sorry. My bad. I've seen it now (ae5795897159319923b60f5c141a2ae5aa6f8d68). Thanks